7:55 a.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJuXs8ACgkQeiVVYja6o6N2tgCfXEppjzE74YuORa+B7jAjBFGZ
0oMAn1h9GP+GVjJ4qYiVUVZ6K7gol5Sk
=cFLM
-----END PGP SIGNATURE-----
7:58 a.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
8:07 a.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJuYYYACgkQeiVVYja6o6MT3gCfSMVTWuAAm8ge2KfKtUoMoF4S
gMIAn00RfxM21pJtO0ScHVTAqXd32uIA
=liws
-----END PGP SIGNATURE-----
8:22 a.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
1:21 p.m.
On Mon, Oct 28, 2013 at 1:55 PM, Stephen Gallagher <sgallagh(a)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
3:26 p.m.
On 10/29/2013 06:21 PM, Miloslav Trmač wrote:
On Mon, Oct 28, 2013 at 1:55 PM, Stephen
Gallagher<sgallagh(a)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
3:38 p.m.
On Tue, 29 Oct 2013 20:26:15 +0000
"Jóhann B. Guðmundsson" <johannbg(a)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
3825
days inactive
3826
days old
server@lists.fedoraproject.org
6 comments
5 participants
participants (5)
-
Jóhann B. Guðmundsson -
Kevin Fenzi -
Miloslav Trmač -
Simo Sorce -
Stephen Gallagher