-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
In no particular order (stream of consciousness):
== Voting Members == * Number of voting members for the Working Group. * How long a term do the voting members serve? * Should there be term limits or mandatory breaks? * Should there be reserved chairs for specific constituencies (e.g. QA, Ambassadors, Release Engineering)? * Voting method?[1] * Who can vote?[2] * Recalls?
== Charter == * How do we approve the initial charter?[3] * How do we later amend the charter?[4]
== My initial thoughts == I am open to counter-arguments, naturally.
[1] For simplicity, I suspect we want to stick with range-voting as in the other elections. We already have the tools for this. [2] I recommend we stick with FPCA+1 as a rule for voting. [3] For the initial charter, I think if it's not unanimous, we need to keep talking. [4] I think amendments should require "voting members - 1". It shouldn't be possible for a single dissenting vote to hold things up (they should get to have their say), but otherwise I think that a near-unanimous vote should be required to change the fundamental guiding document.
On Mon, 2013-10-28 at 08:55 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
In no particular order (stream of consciousness):
== Voting Members ==
- Number of voting members for the Working Group.
- How long a term do the voting members serve?
- Should there be term limits or mandatory breaks?
- Should there be reserved chairs for specific constituencies (e.g.
QA, Ambassadors, Release Engineering)?
- Voting method?[1]
- Who can vote?[2]
- Recalls?
== Charter ==
- How do we approve the initial charter?[3]
- How do we later amend the charter?[4]
== My initial thoughts == I am open to counter-arguments, naturally.
[1] For simplicity, I suspect we want to stick with range-voting as in the other elections. We already have the tools for this.
+1
[2] I recommend we stick with FPCA+1 as a rule for voting.
I am not sure what FPCA+1 is, half + 1 ? If so +1
[3] For the initial charter, I think if it's not unanimous, we need to keep talking.
+1
[4] I think amendments should require "voting members - 1". It shouldn't be possible for a single dissenting vote to hold things up (they should get to have their say), but otherwise I think that a near-unanimous vote should be required to change the fundamental guiding document.
+1
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon 28 Oct 2013 08:58:03 AM EDT, Simo Sorce wrote:
On Mon, 2013-10-28 at 08:55 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
In no particular order (stream of consciousness):
== Voting Members == * Number of voting members for the Working Group. * How long a term do the voting members serve? * Should there be term limits or mandatory breaks? * Should there be reserved chairs for specific constituencies (e.g. QA, Ambassadors, Release Engineering)? * Voting method?[1] * Who can vote?[2] * Recalls?
== Charter == * How do we approve the initial charter?[3] * How do we later amend the charter?[4]
== My initial thoughts == I am open to counter-arguments, naturally.
[1] For simplicity, I suspect we want to stick with range-voting as in the other elections. We already have the tools for this.
+1
[2] I recommend we stick with FPCA+1 as a rule for voting.
I am not sure what FPCA+1 is, half + 1 ? If so +1
FPCA+1 means "Must be a member of at least one FAS group besides "fpca" (which means you signed the Fedora Project Contributor Agreement). It's a balance between allowing anyone to vote vs. contributors (which includes QA, ambassadors, doc writers etc.).
[3] For the initial charter, I think if it's not unanimous, we need to keep talking.
+1
[4] I think amendments should require "voting members - 1". It shouldn't be possible for a single dissenting vote to hold things up (they should get to have their say), but otherwise I think that a near-unanimous vote should be required to change the fundamental guiding document.
I should clarify that this stance is contingent upon a fixed voting membership size. If we decided on a charter that says "Anyone who shows up at a meeting can vote", then this won't work.
+1
Simo.
On Mon, 2013-10-28 at 09:07 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon 28 Oct 2013 08:58:03 AM EDT, Simo Sorce wrote:
On Mon, 2013-10-28 at 08:55 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
In no particular order (stream of consciousness):
== Voting Members == * Number of voting members for the Working Group. * How long a term do the voting members serve? * Should there be term limits or mandatory breaks? * Should there be reserved chairs for specific constituencies (e.g. QA, Ambassadors, Release Engineering)?
Forgot to comment on this earlier. I think it is premature to think in terms of mandatory breaks or forced seats. We should see how much participation we get, and then after a term or 2 amendments can be proposed to limit re-elections if we see the same old people always sitting there although a great many self nominations come through at every election.
- Voting method?[1] * Who can
vote?[2] * Recalls?
== Charter == * How do we approve the initial charter?[3] * How do we later amend the charter?[4]
== My initial thoughts == I am open to counter-arguments, naturally.
[1] For simplicity, I suspect we want to stick with range-voting as in the other elections. We already have the tools for this.
+1
[2] I recommend we stick with FPCA+1 as a rule for voting.
I am not sure what FPCA+1 is, half + 1 ? If so +1
FPCA+1 means "Must be a member of at least one FAS group besides "fpca" (which means you signed the Fedora Project Contributor Agreement). It's a balance between allowing anyone to vote vs. contributors (which includes QA, ambassadors, doc writers etc.).
This is for election of the committee right ? Indeed FPCA + 1 makes sense to me.
[3] For the initial charter, I think if it's not unanimous, we need to keep talking.
+1
[4] I think amendments should require "voting members - 1". It shouldn't be possible for a single dissenting vote to hold things up (they should get to have their say), but otherwise I think that a near-unanimous vote should be required to change the fundamental guiding document.
I should clarify that this stance is contingent upon a fixed voting membership size. If we decided on a charter that says "Anyone who shows up at a meeting can vote", then this won't work.
That's what I think, however it does make sense to allow a larger participation for the charter or the committee can become self-referential.
Proposal 1: I would say a qualified majority of Fedora Contributors plus and of current committee members should be allowed to pass amendments.
Ie, once an amendment is proposed it needs a 6 out of 9 votes from the committee, and a 6 out of 9 positive votes among all that voted, elections are done n parallel.
Proposal 2: Alternatively in order to put an amendment up for vote you need a qualified majority in the committee (not sure how many votes). Once that's up you need a qualified majority of votes from Fedora Contributors (simple majority of voters, not half+1 of all Fedora Contributors in existence).
The balance between prop1 and prop2 is quite different, Prop1 is about giving the more involved members a sort of bland veto vote if many members are against something.
Number 2 is more skewed towards committee being a filter, and vote from Contributors is more like a yes/no referendum. But I think it would avoid situations, where some crazy folks want to keep trying to change the charter. With prop2 they will have to convince the committee that it is a good idea. The committee vote is only about whether the proposal makes sense to put up to a general vote. The committee vote is not about whether members *like* the proposal, they just filter sensible proposals from crap. It is true that the committee may struck down a sensible proposal just because they do not like it if it passed but I assume honorable committee members that want to be re-elected later.
Simo.
On Mon, Oct 28, 2013 at 1:55 PM, Stephen Gallagher sgallagh@redhat.com wrote:
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
Proposals in-line; in general, I prefer not worrying about this too much / not inventing too much now, and getting to the real work instead. We can adjust the rules after a few months when we see what is/isn't working.
== Voting Members ==
- Number of voting members for the Working Group.
Let's assume to continue with 9.
- How long a term do the voting members serve?
FESCo-like, 2 groups of 1 year each, overlapping for 6 months.
Elections to happen within the "combined election cycle" together with FESCo/Board etc. . (I'm unsure about including the elections that are planned soon after the PRD deliverable - it might be a good time to see how the community feels about the PRD, OTOH by that time we'll still not have enough idea about the actual implementation proces.)
The 2 groups can be seeded by voting all seats in the first election, with the top 5 seats to be for 12 months, and the next 4 seats for 6 months.
- Should there be term limits or mandatory breaks?
Let's not worry about that now. We haven't felt the need for them in the other bodies so far.
- Should there be reserved chairs for specific constituencies (e.g.
QA, Ambassadors, Release Engineering)?
Let's not worry about that now. (?)
- Who can vote?[2]
FPCA+1, with an unenforced request for only people participating in the server product to vote?
- Recalls?
Let's not worry about that now. We haven't felt the need for them in the other bodies so far.
- How do we later amend the charter?[4]
[4] I think amendments should require "voting members - 1". It shouldn't be possible for a single dissenting vote to hold things up (they should get to have their say), but otherwise I think that a near-unanimous vote should be required to change the fundamental
Assuming this to be a rare situation, I'd prefer not making up too complex rules for this, we should just avoid the risk of obvious abuse. The above, or "5 voting members + FESCo ACK" would work for me. Mirek
On 10/29/2013 06:21 PM, Miloslav Trmač wrote:
On Mon, Oct 28, 2013 at 1:55 PM, Stephen Gallaghersgallagh@redhat.com wrote:
The first goal of the Working Group process is to plan our governance process for future members of the Server Working Group. I think the place we should start is by gathering a list of requirements that a governance charter will need to keep in mind. I'll list my thoughts below, please raise your own concerns as well.
Proposals in-line; in general, I prefer not worrying about this too much / not inventing too much now, and getting to the real work instead. We can adjust the rules after a few months when we see what is/isn't working.
Agreed
== Voting Members ==
- Number of voting members for the Working Group.
Let's assume to continue with 9.
- How long a term do the voting members serve?
FESCo-like, 2 groups of 1 year each, overlapping for 6 months.
How about not copy other governing structures try a new approach ;)
It's better, more fairer and efficient, to no be voting et all but simply make up the server WG with representatives from each sub community as in one of each from these groups documentation,ambassadors,qa,releng,marketing,design,website and the rest from the server community and have them chose within themselves who will be representing on their behalf and for how long.
Once we as in the initial group members are happy about the transformation process from server application to server "product" from all angles of the related communities as in doc,qa,releng,ambassadors,marketing,website,design and server and have successfully pushed through several products through that process ( to try and tested it ), we step down and let the new governing structure take over.
JBG
On Tue, 29 Oct 2013 20:26:15 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
How about not copy other governing structures try a new approach ;)
It's better, more fairer and efficient, to no be voting et all but simply make up the server WG with representatives from each sub community as in one of each from these groups documentation,ambassadors,qa,releng,marketing,design,website and the rest from the server community and have them chose within themselves who will be representing on their behalf and for how long.
I was just going to send something about the voting aspect of this, but you beat me to it. :)
If there's a way we can come up with that doesn't involve general elections I think that would be nice. Fedora should be/is supposed to be/would be nice if it was, a meritocracy... so we should try and have voting members in the working group who merit it.
Perhaps we could come up with a critera for "active participant" (ie, attends the majority of meetings, has posted to the mailing list in the last month, etc and get our new members from this pool of people who are actually participating/interested in the group.
Once we as in the initial group members are happy about the transformation process from server application to server "product" from all angles of the related communities as in doc,qa,releng,ambassadors,marketing,website,design and server and have successfully pushed through several products through that process ( to try and tested it ), we step down and let the new governing structure take over.
Well, we may not have people from each of those groups interested in being voting members. Additionally, it might be nice to gradually replace people so we don't get a great change of direction at once.
kevin
server@lists.fedoraproject.org
-
Jóhann B. Guðmundsson -
Kevin Fenzi -
Miloslav Trmač -
Simo Sorce -
Stephen Gallagher