I promised I'd work on what the council proposal would look like as an actual wiki page to replace http://fedoraproject.org/wiki/Board. So, is a draft:
https://fedoraproject.org/wiki/MatthewMiller/council-draft
As mentioned in this Monday's IRC meeting, I'd like to get to a point where we can feel good about approving this at next Monday's meeting. The process we used in https://fedorahosted.org/board/ticket/9 was really helpful, and is similar to the planned consensus-finding process for the future. I'm not calling for votes yet, but, board members, please respond with comments and particularly list as bullet points issues which you might have which would prevent you from voting +1 to this.
I'm going to make edits and adjustments as comments come in; to keep that from being confusing, if the concern is over a specific wording, please quote or link to the specific revision in mediawiki.
If you have suggestions for what might go in some of the TODO areas, please include those in your comments as well. I figured it was better and more helpful to post an early draft with some work needed than to wait.
If you are not a current board member, please don't comment in this ticket, but DO comment on the board-discuss mailing list. I'm reading both — it'll just help me keep things organized. Thank you!
Commands, comments, whatever. Enough writing for me for the day, clearly.
I like this draft. There are a couple of minor wording items I might suggest, but they don't change the meaning of any of the statements and in the spirit of moving towards closure I'll refrain. Overall, I approve.
Thanks Josh! Go ahead and send me minor wording items (on discuss list or IRC -- actually, #fedora-board is probably the best place; although I'm in a zillion meetings today and may not notice till later, I will look).
I suggest that we rename {Engineering,Outreach} Lead back to representatives, like the elected seat. 1. that clearly indicates that elected and community-appointed seats have the same "ranking". Just a vocabulary simplification 2. people may mistakenly consider that lead == chairman which may or may not be the case.
I also like this draft. I have a few nitpicks/clarifications/questions that we can iron out as we go, but they aren't enough to be worth holding things up right now. If you're interested, here they are:
Replying to [comment:5 gholms]:
Cool, thanks. Might as well work on the polish while we're here.
The Responsibilities section should be consistent about whether the project has sponsors or a sponsor.
Previous Board doc used "sponsor(s)", which I guess we could too, or "sponsor or sponsors". Practically speaking, we have just the one right now but it might be nice to leave the language open.
I think the point-by-point bit with the Council's responsibilities can simply be deleted.
Done. I moved the two lines that weren't covered in the other text to the intro -- stewardship of the project as a whole and health and growth of the community.
The Engineering and Outreach Leads should be called Representatives to preclude confusion and keep things consistent.
Okay, with two people saying that I'm going to go ahead and do that.
Keep the two different types of limited voting positions together. For example, this order reads a little nicer: Representatives Appointed Leaders Auxiliary Seats Objective-specific Seats
Let me see how that looks. I intentional put the objective-specific seats first to emphasize them.
Who selects the Diversity Adviser and Program Manager, and how?
I think in both cases, suitability for the role is a little different from the rest, where finding someone really excellent for the job may be different from finding someone with accumulated merit within the project. For the Program Manager, I think it's "Red Hat hire, with council approval". (If Red Hat hires someone who can't work with the council, it's a non-starter, so might as well say so.) And right now, it is specifically Jaroslav, who is both hired in that way and who has a lot of actual practical project merit, so... yeah. The Diversity Advisor is in some ways an extension of the existing administrator of our involvement in OPW and other programs. Máirín Duffy does that right now, and if she's willing to increase that responsibility (I talked to her briefly about it) I think that'd be awesome; if not, or for future selections, I think a search committee appointed by the council is appropriate. (This is not a paid position at this point; I am talking to our-sponsor-singular about ways in which the company can support this role.)
Also, I went ahead and added the Governance Philosophy paragraph from the previous board documentation and http://fedoraproject.org/wiki/Meeting:Board_meeting_2010-02-11#Importance_of_strategy
So, I put
This position is appointed by the Fedora Project Leader, with the approval of the Council.
for the Diversity Advisor (FDA?). Kind of trying that on for size; what do you all think?
Based on mailing list suggestions, I codified that the elected positions are staggered, and that the initial selection will be with a single election taking the winning-est candidate for a full term and the runner up for a half term.
I apologize for not having time to look this over before now but the past couple of weeks have been brutal in other areas of life. Rather than thinking about these comments as objections try to look at them as questions asked to help me understand some points in the proposal better. At this point I'm just looking for some explanations and I'm not offering specific objections.
First, beginning near the end I don't think it is accurate to suggest that the FPL has any less of a veto power under this system than previously. The FPL can vote -1 which blocks any proposal and even if escalated for the FPL to then decide because the Council is stuck the FPL still votes -1 to effect the veto. I don't object to the FPL having such power, but I don't think it is accurate to suggest the FPL has a more limited power. Also, I think we spend way too much time talking about a power that hasn't been used in the history of the project.
Second, the section governing selection of Elected Representatives it says:
Why do we want to restrict these two community elected positions in this way when four other positions appointed by Red Hat or the Council serve indefinitely at the pleasure of Red Hat or the Council? Is there some harm you see according the same notion of indefinite terms at the pleasure of the community?
Third, I still have some discomfort regarding the resolution of matters that don't reach consensus. Where did the number three come from when deciding what is needed for a measure to be adopted? That seems arbitrary and quite small, although the actual size of the pool of voters on measures will vary depending on the issue which makes this a bit fuzzy.
Why isn't there a similar number for dispatching issues that fall the other direction? Say, three negative votes and no positive votes kills a measure by the same consensus doesn't it?
What is the incentive for a single dissenter to try to convince a second member of the council to join in the dissent if all that accomplishes is that the FPL decides the issue? That would happen even without the second dissenter as described here?
I could go on a bit more here but I think I'll wait for some feedback on this point as my fairly literal reading might not line up with what you really mean.
A couple of wording items:
In the FPgM strike the work "Board" and replace with Council if that is the intention.
Please don't call public contact with the community "office hours." People find that condescending and suggestive of a strong power discrepency (teacher vs. student for example).
A lot of the discussion here so far has been on voting; who gets a vote, what constitutes an accepted vote, how the voters are selected, how a vote is blocked, and so on.
While a lot of things definitely will need to come down to a vote, I strongly believe that the charge given to this council should not be one of producing voted decisions. The current board is arguably vote-centric, and perhaps part of the struggle for that body to have influence comes from a posture of waiting for questions to be posed that require a voting decision.
To an active coordinating body, I think that voting should be an ancillary function. The group should be working to coordinate strategy from stakeholders and the community at large, and produce tactics defined and accepted by the same. To me, at least, the intention for the council to operate this way is evident - but I'm concerned that the focus on voting might lead to a body focused on voting. Or perhaps worse - lead people to appoint or elect members based on how they might vote, instead of how they might interact with the community.
I'm reminded of a passage from The Open Source Way:
{{{ Most decisions in an open community are not decided by a vote. As in a well-working democracy, decisions are handled by the experts and knowledgeable people who are in charge at the will of the people around them.
Voting is best left for deciding who is in charge and the occasional very contentious issue. Don't you wish it weren't contentious? Wish you could go back and make a consensus? }}}
I don't have any specific suggestions on how to codify that, but I hope the comments can be useful to someone that can.
Replying to [comment:10 inode0]:
Yeah; I'm open to different wording, or even to just striking it. (I added it at Rahul's suggestion based on list discussion.) I would like to somehow get in there that like the previous veto power, it's really a last resort and I expect it to continue to not be used.
Second, the section governing selection of Elected Representatives it says: No person who currently holds another Council seat can be elected, nor can anyone be elected twice in a row (although the same person may be elected multiple times, with a break in between). Why do we want to restrict these two community elected positions in this way when four other positions appointed by Red Hat or the Council serve indefinitely at the pleasure of Red Hat or the Council? Is there some harm you see according the same notion of indefinite terms at the pleasure of the community?
My concern is with the same people being elected continuously on name recognition rather than on platform; it's easy to fall into this. Not that those people aren't usually great, just that it gives a chance for others and for their new ideas.
What does everyone else think about this?
+3 is mostly arbitrary. I picked that particular arbitrary value because A) It's what Apache uses for decisions, and for that matter CentOS too, although in both cases their overall structure is different. (With Apache, it's often a very large number of potential voters; with CentOS, as Karsten was saying on the mailing list, it's a small number but may grow in the future) and B) a smaller number tilts towards action.
Would we ''want'' something where there's three positive votes and three "This is fine / I don't care either way"s to fail?
No, it's much stronger. Just -1 blocks the measure. Or do you mean something like some number of negative votes removes the topic from discussion entirely?
A group decision which everyone finds acceptable is in everyone's interest. If the dissenter thinks that the FPL will simply rule completely against their views, it's in their interest to help find a compromise position which would be more acceptable than that. The emphasis shouldn't be on convincing people to join sides (a power-struggle situation), but on getting issues with the proposal resolved if at all possible. And it's the responsibility of the proponents of the proposal to work to address the concerns of members voting -1.
In some models, single -1 votes cease to be blocking after a period of time, so a lone dissenter has to find support for that position. But I think that's more suited to a much larger body, and I think it kind of encourages political wrangling, and puts too much emphasis on the negative side.
I'm open to adding something which makes situations where the FPL needs to unblock have a built-in followup consequence, beyond just everything in that which is we inherently want to avoid. Someone mentioned that in CentOS, if this happens, the mechanism is that the dissenter is actually removed from the board. I don't think that's what we want to do, but maybe having something that strong would help.
A couple of wording items: In the FPgM strike the work "Board" and replace with Council if that is the intention.
Done. Simply pasted from earlier proposal text.
That didn't occur to me, but point taken. Alternate suggestions? (This wasn't meant to be a name for all communication with the community, of course; just a specific time when I'll promise to be generally available.)
Replying to [comment:12 mattdm]:
Replying to [comment:10 inode0]: First, beginning near the end I don't think it is accurate to suggest that the FPL has any less of a veto power under this system than previously. The FPL can vote -1 which blocks any proposal and even if escalated for the FPL to then decide because the Council is stuck the FPL still votes -1 to effect the veto. I don't object to the FPL having such power, but I don't think it is accurate to suggest the FPL has a more limited power. Also, I think we spend way too much time talking about a power that hasn't been used in the history of the project. Yeah; I'm open to different wording, or even to just striking it. (I added it at Rahul's suggestion based on list discussion.) I would like to somehow get in there that like the previous veto power, it's really a last resort and I expect it to continue to not be used.
Reading it over a few more times it isn't really a big deal.
Second, the section governing selection of Elected Representatives it says: No person who currently holds another Council seat can be elected, nor can anyone be elected twice in a row (although the same person may be elected multiple times, with a break in between). Why do we want to restrict these two community elected positions in this way when four other positions appointed by Red Hat or the Council serve indefinitely at the pleasure of Red Hat or the Council? Is there some harm you see according the same notion of indefinite terms at the pleasure of the community? My concern is with the same people being elected continuously on name recognition rather than on platform; it's easy to fall into this. Not that those people aren't usually great, just that it gives a chance for others and for their new ideas.
Why don't we have the same concern for the other elected positions? Aren't they subject to the same thing potentially happening?
What does everyone else think about this? Third, I still have some discomfort regarding the resolution of matters that don't reach consensus. Where did the number three come from when deciding what is needed for a measure to be adopted? That seems arbitrary and quite small, although the actual size of the pool of voters on measures will vary depending on the issue which makes this a bit fuzzy. +3 is mostly arbitrary. I picked that particular arbitrary value because A) It's what Apache uses for decisions, and for that matter CentOS too, although in both cases their overall structure is different. (With Apache, it's often a very large number of potential voters; with CentOS, as Karsten was saying on the mailing list, it's a small number but may grow in the future) and B) a smaller number tilts towards action.
Ok, that makes sense to me.
No, but I might want something with three positive votes and three "I'm not voting against this but I am against it for these reasons" to fail or at least continue to be discussed.
Why isn't there a similar number for dispatching issues that fall the other direction? Say, three negative votes and no positive votes kills a measure by the same consensus doesn't it? No, it's much stronger. Just -1 blocks the measure. Or do you mean something like some number of negative votes removes the topic from discussion entirely?
Yeah, I may be confused a bit here. I think it would help me a lot if you could define with some precision what situation constitutes a lack of consensus where the Council might ask the FPL to simply decide the matter.
If there's no positive votes, I think that will happen naturally and there's no need for rules. If there are some positive votes and some negative ones, then it seems like something we ''should'' work out with further discussion. If there's just one positive vote and that one person isn't able to convince anyone else after a period of time, I think that too will probably happen naturally. What is the incentive for a single dissenter to try to convince a second member of the council to join in the dissent if all that accomplishes is that the FPL decides the issue? That would happen even without the second dissenter as described here? A group decision which everyone finds acceptable is in everyone's interest. If the dissenter thinks that the FPL will simply rule completely against their views, it's in their interest to help find a compromise position which would be more acceptable than that. The emphasis shouldn't be on convincing people to join sides (a power-struggle situation), but on getting issues with the proposal resolved if at all possible. And it's the responsibility of the proponents of the proposal to work to address the concerns of members voting -1. In some models, single -1 votes cease to be blocking after a period of time, so a lone dissenter has to find support for that position. But I think that's more suited to a much larger body, and I think it kind of encourages political wrangling, and puts too much emphasis on the negative side. I'm open to adding something which makes situations where the FPL needs to unblock have a built-in followup consequence, beyond just everything in that which is we inherently want to avoid. Someone mentioned that in CentOS, if this happens, the mechanism is that the dissenter is actually removed from the board. I don't think that's what we want to do, but maybe having something that strong would help.
I'll wait until I understand the lack of consensus situation better before going down another rabbit hole here.
A couple of wording items: In the FPgM strike the work "Board" and replace with Council if that is the intention. Done. Simply pasted from earlier proposal text. Please don't call public contact with the community "office hours." People find that condescending and suggestive of a strong power discrepency (teacher vs. student for example). That didn't occur to me, but point taken. Alternate suggestions? (This wasn't meant to be a name for all communication with the community, of course; just a specific time when I'll promise to be generally available.)
In this context we could just say that the FPL will set aside regular times on IRC to meet with the community. I can imagine having a name for it would be helpful in announcements and such but I don't think it matters in this document.
Replying to [comment:13 inode0]:
Easy; done. Now, off to make dinner for my kids and will think more about the rest. :)
Replying to [comment:12 mattdm]: My concern is with the same people being elected continuously on name recognition rather than on platform; it's easy to fall into this. Not that those people aren't usually great, just that it gives a chance for others and for their new ideas. Why don't we have the same concern for the other elected positions? Aren't they subject to the same thing potentially happening?
My concern is with the same people being elected continuously on name recognition rather than on platform; it's easy to fall into this. Not that those people aren't usually great, just that it gives a chance for others and for their new ideas. Why don't we have the same concern for the other elected positions? Aren't they subject to the same thing potentially happening?
I have that concern there too, but it's balanced somewhat by a desire for continuity in the positions that are directly representative of the outreach and building halves of the project, and by the fact that those positions will be chosen by the active committees in those areas.
Would we want something where there's three positive votes and three "This is fine / I don't care either way"s to fail? No, but I might want something with three positive votes and three "I'm not voting against this but I am against it for these reasons" to fail or at least continue to be discussed.
Some of this will come down to operating conventions which we will evolve in practice (but some of which we might codify now.) One thing we can do is define "-1" as "hold on", rather than "I hate this it must die". That way, it can express "I'm not necessarily going to stand against this but have these reservations", and you can change to 0 (or even +1) once you're satisfied that the concerns have been listened to or addressed. Or, we could say that a "0 with concerns" vote automatically turns to a -1 if those concerns aren't discussed. (Just as a -1 without reasonable explanation automatically turns to a 0 -- in either case, discussion of the concerns and "what would it take to make this a yes?" gets the emphasis.)
No, it's much stronger. Just -1 blocks the measure. Or do you mean something like some number of negative votes removes the topic from discussion entirely? Yeah, I may be confused a bit here. I think it would help me a lot if you could define with some precision what situation constitutes a lack of consensus where the Council might ask the FPL to simply decide the matter.
I think the most likely situation is when there's one sticking point which a single member feels that they can't compromise on, but everyone else feels necessary, and everyone feels like all options have been exhausted (that's why there's the part about two weeks of discussion). The more difficult situation would be when the council has a more even split, likely one that's reflective of a big division in the project as a whole. In that case, project-wide discussion should continue as long as it continues to be constructive and productive. I can imagine a situation where that would reach its limit, and we'd need to pick one way or another and move on. That should be both a big deal and rare, and as I noted above, we might build some automatic post-mortem requirement when it happens (although I think that it's probably not something we need to over-engineer for).
Replying to [comment:15 mattdm]:
Replying to [comment:13 inode0]: Replying to [comment:12 mattdm]: My concern is with the same people being elected continuously on name recognition rather than on platform; it's easy to fall into this. Not that those people aren't usually great, just that it gives a chance for others and for their new ideas. Why don't we have the same concern for the other elected positions? Aren't they subject to the same thing potentially happening? I have that concern there too, but it's balanced somewhat by a desire for continuity in the positions that are directly representative of the outreach and building halves of the project, and by the fact that those positions will be chosen by the active committees in those areas.
I don't know how the outreach and building groups will select representatives from what I've read so far. The proposal does not call for committee selection. While FESCo naturally subsumes all of the distro/product building groups, FAmSCo is just an ambassador body.
Thus far I haven't heard what to me is a compelling reason to treat the two seats elected directly by the entire community differently. Part of the expressed responsibility of those seats will be to pursue specific goals advertised during the election process. What if those goals don't have a timetable that can be effectively achieved in one year? I don't see any reason to structurally prevent the community at large from saying this person has done good work toward those goals and we would like him/her to continue for another year. Perhaps the community would simply prefer continuity in its representation too.
Replying to [comment:16 inode0]:
That is a bit uncharted. Thanks for highlighting it. We could ask for a special selection committee comprised of representatives from: Ambassadors, Marketing, Docs, Websites, and Ask Fedora? (Maybe also IRC Support SIG? Anything else?) FESCo could do a similar thing, although as you say it's already structured in a way that makes it a natural point as is. For the outreach side, do you think it's problematic to ask FAmSCo to organize that and be inclusive, even though it's bigger than the scope they've traditionally had?
I'm not strongly stuck on this, and can be convinced that we should change it. Possibly some work on revitalizing the election process -- and focusing on those advertised goals as you mention -- can have the same effect.
Does anyone else have othre specific points to discuss for this afternoon's meeting?
Replying to [comment:17 mattdm]:
Replying to [comment:16 inode0]: I don't know how the outreach and building groups will select representatives from what I've read so far. The proposal does not call for committee selection. While FESCo naturally subsumes all of the distro/product building groups, FAmSCo is just an ambassador body. That is a bit uncharted. Thanks for highlighting it. We could ask for a special selection committee comprised of representatives from: Ambassadors, Marketing, Docs, Websites, and Ask Fedora? (Maybe also IRC Support SIG? Anything else?) FESCo could do a similar thing, although as you say it's already structured in a way that makes it a natural point as is. For the outreach side, do you think it's problematic to ask FAmSCo to organize that and be inclusive, even though it's bigger than the scope they've traditionally had?
Personally I would rather have a FESCo equivalent on the outreach side. I think it would make a more logical body to integrate things into all those various areas and to develop strategies for presenting Fedora (both the Project and the Products) to the public.
Replying to [comment:19 inode0]:
Replying to [comment:17 mattdm]: Replying to [comment:16 inode0]: I don't know how the outreach and building groups will select representatives from what I've read so far. The proposal does not call for committee selection. While FESCo naturally subsumes all of the distro/product building groups, FAmSCo is just an ambassador body. That is a bit uncharted. Thanks for highlighting it. We could ask for a special selection committee comprised of representatives from: Ambassadors, Marketing, Docs, Websites, and Ask Fedora? (Maybe also IRC Support SIG? Anything else?) FESCo could do a similar thing, although as you say it's already structured in a way that makes it a natural point as is. For the outreach side, do you think it's problematic to ask FAmSCo to organize that and be inclusive, even though it's bigger than the scope they've traditionally had? Personally I would rather have a FESCo equivalent on the outreach side. I think it would make a more logical body to integrate things into all those various areas and to develop strategies for presenting Fedora (both the Project and the Products) to the public.
I don't necessarily disagree, but that is going to take a while to bootstrap. Having such a body in place as a prerequisite to the Board rework seems unnecessary. I think it would be possible to deal with selecting a representative now, and having them work towards that as one of the first goals.
Oh hmmm. I didn't put anything in there about what happens if an elected seat becomes vacant.
"If a seat becomes vacant, a special election will be held."?
What if there's only two weeks before the next regular election? Or one month?
I would say that in the case of less than 1 month before the next regular election the seat is left open until the next election. You could come up with a way that a temporary person can be appointed (and possibly approved by the rest of the council) to take that seat until either the next election (be it general or special)
Other bodies tended to add this sort of detail later, in some cases years later. I'm fine with the Council sorting this out for all vacant seats at some point. For now I don't think the details of this is a critical part of the proposal.
Thanks. I'm going to leave it vague for now and we can codify it later.
Closing this ticket -- now time for voting in https://fedorahosted.org/board/ticket/13
Thank you very much for your help in constructing this, everyone. I'm sure it's not what I would have invented on my own, but is instead much better.