[aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
This proposal clarifies the Standard Voting Procedure, and allows another condition for passing a motion. Signed-off-by: Loui Chang <louipc.ist@gmail.com> --- TUbylaws.html | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/TUbylaws.html b/TUbylaws.html index 2c4b854..a3fa84d 100644 --- a/TUbylaws.html +++ b/TUbylaws.html @@ -10,8 +10,8 @@ </head><body> <h1>Trusted User Bylaws</h1> - <div class="date">May 21, 2008</div> - <div class="version">1.1</div> + <div class="date">2010-12-05</div> + <div class="version">1.2</div> <address> Trusted Users @@ -79,9 +79,12 @@ <br><br> At the expiration of the voting period, if a quorum was reached, votes are to be tallied. - A simple majority is needed to pass or reject the motion. In the event of a draw, being - that 50% is not a majority, the motion does not pass. In the event that a quorum was not - reached, a duplicate voting period opens immediately after the first ends, all previous votes are + The motion is passed if quorum is reached and the number of YES votes is greater than the number of NO votes. + The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. + The motion is rejected if quorum is reached and the number of NO votes is greater or equal to the number of YES votes. + + In the event that a quorum was not reached and the motion is not passed, + a duplicate voting period opens immediately after the first ends, all previous votes are struck from the record, and the voting period is repeated. If quorum cannot be reached for two consecutive voting periods, the motion fails to pass.<br><br> -- 1.7.3.2
On Sun, Dec 5, 2010 at 4:13 PM, Loui Chang <louipc.ist@gmail.com> wrote:
This proposal clarifies the Standard Voting Procedure, and allows another condition for passing a motion.
<address> Trusted Users @@ -79,9 +79,12 @@ <br><br>
At the expiration of the voting period, if a quorum was reached, votes are to be tallied. - A simple majority is needed to pass or reject the motion. In the event of a draw, being - that 50% is not a majority, the motion does not pass. In the event that a quorum was not - reached, a duplicate voting period opens immediately after the first ends, all previous votes are + The motion is passed if quorum is reached and the number of YES votes is greater than the number of NO votes. + The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. + The motion is rejected if quorum is reached and the number of NO votes is greater or equal to the number of YES votes. + + In the event that a quorum was not reached and the motion is not passed, + a duplicate voting period opens immediately after the first ends, all previous votes are struck from the record, and the voting period is repeated. If quorum cannot be reached for two consecutive voting periods, the motion fails to pass.<br><br>
Looks good to me, except "greater or equal to" is usually written as "greater than or equal to". --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Sun 05 Dec 2010 16:19 -0500, Kaiting Chen wrote:
On Sun, Dec 5, 2010 at 4:13 PM, Loui Chang <louipc.ist@gmail.com> wrote:
This proposal clarifies the Standard Voting Procedure, and allows another condition for passing a motion.
<address> Trusted Users @@ -79,9 +79,12 @@ <br><br>
At the expiration of the voting period, if a quorum was reached, votes are to be tallied. - A simple majority is needed to pass or reject the motion. In the event of a draw, being - that 50% is not a majority, the motion does not pass. In the event that a quorum was not - reached, a duplicate voting period opens immediately after the first ends, all previous votes are + The motion is passed if quorum is reached and the number of YES votes is greater than the number of NO votes. + The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. + The motion is rejected if quorum is reached and the number of NO votes is greater or equal to the number of YES votes. + + In the event that a quorum was not reached and the motion is not passed, + a duplicate voting period opens immediately after the first ends, all previous votes are struck from the record, and the voting period is repeated. If quorum cannot be reached for two consecutive voting periods, the motion fails to pass.<br><br>
Looks good to me, except "greater or equal to" is usually written as "greater than or equal to". --Kaiting.
Ah right good catch. Let's see what others think now before revising.
Hi, This looks good to me, and seems clearer. One minor suggestion: On Sunday 05 December 2010 21:13:55 Loui Chang wrote:
At the expiration of the voting period, if a quorum was reached, votes are to be tallied. -A simple majority is needed to pass or reject the motion. In the event -of a draw, being that 50% is not a majority, the motion does not pass. In -the event that a quorum was not reached, a -duplicate voting period opens immediately after the first ends, all -previous votes are
+The motion is passed if quorum is reached and the number of YES votes is +greater than the number of NO votes. The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. +The motion is rejected if quorum is reached and the number of NO votes is +greater or equal to the number of YES votes.
+In the event that a quorum was not reached and the motion is not passed,
Possibly change this last line to "In the event that the motion is not passed due to quorum not having been reached," ?
+a duplicate voting period opens immediately after the first ends, all +previous votes are struck from the record, and the voting period +is repeated. If quorum cannot be reached for two consecutive voting +periods, the motion fails to pass.<br><br>
Good work :-) Pete.
On Sun, 5 Dec 2010 16:13:55 -0500 Loui Chang <louipc.ist@gmail.com> wrote:
This proposal clarifies the Standard Voting Procedure, and allows another condition for passing a motion.
Signed-off-by: Loui Chang <louipc.ist@gmail.com> --- TUbylaws.html | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/TUbylaws.html b/TUbylaws.html index 2c4b854..a3fa84d 100644 --- a/TUbylaws.html +++ b/TUbylaws.html @@ -10,8 +10,8 @@ </head><body> <h1>Trusted User Bylaws</h1>
- <div class="date">May 21, 2008</div> - <div class="version">1.1</div> + <div class="date">2010-12-05</div> + <div class="version">1.2</div>
<address> Trusted Users @@ -79,9 +79,12 @@ <br><br>
At the expiration of the voting period, if a quorum was reached, votes are to be tallied. - A simple majority is needed to pass or reject the motion. In the event of a draw, being - that 50% is not a majority, the motion does not pass. In the event that a quorum was not - reached, a duplicate voting period opens immediately after the first ends, all previous votes are + The motion is passed if quorum is reached and the number of YES votes is greater than the number of NO votes. + The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. + The motion is rejected if quorum is reached and the number of NO votes is greater or equal to the number of YES votes. + + In the event that a quorum was not reached and the motion is not passed, + a duplicate voting period opens immediately after the first ends, all previous votes are struck from the record, and the voting period is repeated. If quorum cannot be reached for two consecutive voting periods, the motion fails to pass.<br><br>
So far it is mostly fine for me, however from this paragraph it is not clear if the vote is still open when the quorum was reached and the application passed. In my opinion it should be, so everyone has the chance to do a vote and express his way though it doesn't matter. (Yes it does not make any formal sense, however I think about human emotions that it's better to do so, so no one feels to be excluded just as the vote is another in a row where he/she could not participate. In other words: Kaiting that was what I meant yesterday.) Also I'd say to keep the old date format as it is really clear how it has to be read, I'm not aware of every date format around the world but I have the feeling that this one could be misread as May 12, 2010... -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
On Mon 06 Dec 2010 17:31 +0100, Thorsten Töpper wrote:
On Sun, 5 Dec 2010 16:13:55 -0500 Loui Chang <louipc.ist@gmail.com> wrote:
This proposal clarifies the Standard Voting Procedure, and allows another condition for passing a motion.
Signed-off-by: Loui Chang <louipc.ist@gmail.com> --- TUbylaws.html | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/TUbylaws.html b/TUbylaws.html index 2c4b854..a3fa84d 100644 --- a/TUbylaws.html +++ b/TUbylaws.html @@ -10,8 +10,8 @@ </head><body> <h1>Trusted User Bylaws</h1>
- <div class="date">May 21, 2008</div> - <div class="version">1.1</div> + <div class="date">2010-12-05</div> + <div class="version">1.2</div>
<address> Trusted Users @@ -79,9 +79,12 @@ <br><br>
At the expiration of the voting period, if a quorum was reached, votes are to be tallied. - A simple majority is needed to pass or reject the motion. In the event of a draw, being - that 50% is not a majority, the motion does not pass. In the event that a quorum was not - reached, a duplicate voting period opens immediately after the first ends, all previous votes are + The motion is passed if quorum is reached and the number of YES votes is greater than the number of NO votes. + The motion is also passed if quorum is not reached but the number of YES votes exceeds fifty percent of the number of active Trusted Users. + The motion is rejected if quorum is reached and the number of NO votes is greater or equal to the number of YES votes. + + In the event that a quorum was not reached and the motion is not passed, + a duplicate voting period opens immediately after the first ends, all previous votes are struck from the record, and the voting period is repeated. If quorum cannot be reached for two consecutive voting periods, the motion fails to pass.<br><br>
So far it is mostly fine for me, however from this paragraph it is not clear if the vote is still open when the quorum was reached and the application passed. In my opinion it should be, so everyone has the chance to do a vote and express his way though it doesn't matter. (Yes it does not make any formal sense, however I think about human emotions that it's better to do so, so no one feels to be excluded just as the vote is another in a row where he/she could not participate. In other words: Kaiting that was what I meant yesterday.)
Also I'd say to keep the old date format as it is really clear how it has to be read, I'm not aware of every date format around the world but I have the feeling that this one could be misread as May 12, 2010...
Those changes do not alter the voting period in any way. So the voting period would still run for the same amount of time. Good point about the date.
On Mon, Dec 6, 2010 at 11:31 AM, Thorsten Töpper <atsutane@freethoughts.de>wrote:
So far it is mostly fine for me, however from this paragraph it is not clear if the vote is still open when the quorum was reached and the application passed. In my opinion it should be, so everyone has the chance to do a vote and express his way though it doesn't matter. (Yes it does not make any formal sense, however I think about human emotions that it's better to do so, so no one feels to be excluded just as the vote is another in a row where he/she could not participate. In other words: Kaiting that was what I meant yesterday.)
I'm not really one for human emotion, but I'll go ahead and conceded to a full voting period regardless of whether or not a vote is set. I've read through this a couple more times and I'm little concerned about the particular wording. Unfortunately I don't know how to make this any clearer so I guess I'll shut up... -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Mon 06 Dec 2010 23:08 -0500, Kaiting Chen wrote:
On Mon, Dec 6, 2010 at 11:31 AM, Thorsten Töpper <atsutane@freethoughts.de>wrote:
So far it is mostly fine for me, however from this paragraph it is not clear if the vote is still open when the quorum was reached and the application passed. In my opinion it should be, so everyone has the chance to do a vote and express his way though it doesn't matter. (Yes it does not make any formal sense, however I think about human emotions that it's better to do so, so no one feels to be excluded just as the vote is another in a row where he/she could not participate. In other words: Kaiting that was what I meant yesterday.)
I'm not really one for human emotion, but I'll go ahead and conceded to a full voting period regardless of whether or not a vote is set.
I've read through this a couple more times and I'm little concerned about the particular wording. Unfortunately I don't know how to make this any clearer so I guess I'll shut up...
Honestly, I wouldn't mind hearing your concerns. I realise that I could improve my writing skills at least. Do we have any technical writers in the community? :D
On Mon, Dec 6, 2010 at 11:37 PM, Loui Chang <louipc.ist@gmail.com> wrote:
I've read through this a couple more times and I'm little concerned about the particular wording. Unfortunately I don't know how to make this any clearer so I guess I'll shut up...
Honestly, I wouldn't mind hearing your concerns. I realise that I could improve my writing skills at least.
Do we have any technical writers in the community? :D
I sent the proposed patch to some people who deal with this kind of thing and most of them were confused until I explained it thoroughly. I'm waiting to hear their suggestions. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Mon 06 Dec 2010 23:42 -0500, Kaiting Chen wrote:
On Mon, Dec 6, 2010 at 11:37 PM, Loui Chang <louipc.ist@gmail.com> wrote:
I've read through this a couple more times and I'm little concerned about the particular wording. Unfortunately I don't know how to make this any clearer so I guess I'll shut up...
Honestly, I wouldn't mind hearing your concerns. I realise that I could improve my writing skills at least.
Do we have any technical writers in the community? :D
I sent the proposed patch to some people who deal with this kind of thing and most of them were confused until I explained it thoroughly. I'm waiting to hear their suggestions. --Kaiting.
Wow. I didn't think it was that bad.
On Tue, Dec 7, 2010 at 12:11 AM, Loui Chang <louipc.ist@gmail.com> wrote:
I sent the proposed patch to some people who deal with this kind of thing and most of them were confused until I explained it thoroughly. I'm waiting to hear their suggestions. --Kaiting.
Wow. I didn't think it was that bad.
The wording could use some work. The biggest question I've been getting is "how long is the discussion period between the first and second vote if the quorum fails?". The answer is of course zero, but apparently this is very unorthodox. Also it seems the people are confused by the difference between 'not accepted' and 'rejected', which to my understanding there is none. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Kaiting Chen wrote:
Wow. I didn't think it was that bad.
The wording could use some work. The biggest question I've been getting is "how long is the discussion period between the first and second vote if the quorum fails?". The answer is of course zero, but apparently this is very unorthodox.
Also it seems the people are confused by the difference between 'not accepted' and 'rejected', which to my understanding there is none. --Kaiting.
I've rewritten that section with some changes (see below). I've tried to keep the wording unambiguous and relatively simple. Note the following functional changes: * If 50% or more of all active TUs vote NO then the vote is rejected even in the absence of quorum. This is logically coherent with accepting the vote when more than 50% vote YES in the absence of quorum. * Default durations for various items such as discussion periods and voting periods. I'm not sure about the wording of "... shall normally be ... but may be determined by the nature of the proposal as described elsewhere in the bylaws." and similar passages. The intention is to enable other sections of the bylaws and nothing else to supersede the defaults. For example the TU removal procedure allows for shorter discussion and voting periods. The section thus provides the standard template for voting that can be tweaked by other sections as necessary. The tricky bit is wording it in such a way that the person making the proposal can't arbitrarily change them. SVP SECTION: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall normally be 5 days but may be determined by the nature of the proposal as described elsewhere in the bylaws. All discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall normally be 7 days but may be determined by the nature of the proposal as described elsewhere in the bylaws. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall normally be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, but may be determined by the nature of the proposal as described elsewhere in the bylaws. The proposal is normally accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. The proposal is normally rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall normally be 3 months but may be determined by the nature of the proposal as described elsewhere in the bylaws. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
Hey, On Tuesday 07 December 2010 15:37:41 Xyne wrote:
I've rewritten that section with some changes (see below). I've tried to keep the wording unambiguous and relatively simple. Note the following functional changes:
* If 50% or more of all active TUs vote NO then the vote is rejected even in the absence of quorum. This is logically coherent with accepting the vote when more than 50% vote YES in the absence of quorum.
* Default durations for various items such as discussion periods and voting periods.
I think this is really helpful. A few more thoughts interleaved below, including a suggestion on the "normally" point.
I'm not sure about the wording of "... shall normally be ... but may be determined by the nature of the proposal as described elsewhere in the bylaws." and similar passages. The intention is to enable other sections of the bylaws and nothing else to supersede the defaults. For example the TU removal procedure allows for shorter discussion and voting periods. The section thus provides the standard template for voting that can be tweaked by other sections as necessary. The tricky bit is wording it in such a way that the person making the proposal can't arbitrarily change them.
SVP SECTION:
Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs.
SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general).
Do we require that a proposal has only "yes" and "no" as options, as well as "abstain"? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.)
The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall normally be 5 days but may be
I'd suggest "5 full days" rather than just "5 days", for the removal of any potential ambiguity.
determined by the nature of the proposal as described elsewhere in the bylaws. All discussion shall take place on aur-general. During the discussion period, votes shall not be cast.
I'm not quite sure what "all discussion shall..." means. Does it mean that discussion outside of aur-general is forbidden, not allowed as evidence in a court, etc.? What's the purpose of this line?
The voting period begins when the discussion period ends. The duration of the voting period shall normally be 7 days but may be determined by the nature of the proposal as described elsewhere in the bylaws.
In answer to your "normally" point, perhaps: "The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws."
During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied.
In the context of SVP, TUs are considered active if they are marked as active when the voting period ends.
Quorum shall normally be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, but may be determined by the nature of the proposal as described elsewhere in the bylaws.
again, perhaps just make it a little tighter like above: "Quorum shall be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws."
The proposal is normally accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal.
Same thing, perhaps replace "is normally accepted... ...but these conditions may be superseded" with "is accepted... ...unless these conditions are superseded".
The proposal is normally rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal.
Same thing.
A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall normally be 3 months but may be determined by the nature of the proposal as described elsewhere in the bylaws. The waiting period begins at the end of the voting period.
Same thing.
If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
But yes, I think these are very clear. Well done! Pete.
Peter Lewis wrote:
Do we require that a proposal has only "yes" and "no" as options, as well as "abstain"? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.)
For now those are the only options available on the interface, so we don't need to consider anything else. Eventually "Standard Voting Procedure" could be changed to "Simple Voting Procedure" and another procedure could be introduced for anything beyond an accept/reject motion.
I'm not quite sure what "all discussion shall..." means. Does it mean that discussion outside of aur-general is forbidden, not allowed as evidence in a court, etc.? What's the purpose of this line?
I've changed that to "Official discussion shall...".
I'd suggest "5 full days" rather than just "5 days", for the removal of any potential ambiguity.
I agree and will include that. In practice though, nobody counts the hours.
In answer to your "normally" point, perhaps:
"The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws."
I tried to find a natural-sounding formulation using "unless" too but couldn't. I think it's because I already had "... nature of the proposal..." in my head. I agree with the use of "unless" but not the proposed statement. I've used "UNLESS otherwise stated in a section of the bylaws pertaining to the proposal." in the updated version below.
But yes, I think these are very clear. Well done!
Thanks. Second version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
I've tried to remove further ambiguity from the sections about quorum, acceptance and rejection. I've also reformulated the first case in the rejection section to use similar wording to the acceptance section. Third version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
On Tuesday 07 December 2010 16:58:49 Xyne wrote:
Third version:
Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs.
SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general).
So I'd just suggest also adding: "The proposal must also be worded unambiguously, and such that a YES / NO answer may be given." Looks good to me though :-) Pete.
Hang on, I just went through this again: On Tuesday 07 December 2010 16:58:49 Xyne wrote:
Third version:
Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs.
SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general).
The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast.
The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied.
In the context of SVP, TUs are considered active if they are marked as active when the voting period ends.
Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.
The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.
This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about: " The proposal is accepted if EITHER: A) the number of YES votes is greater than half the number of active TUs, OR B) quorum has been established and the number of YES votes is greater than the number of NO votes; UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. " or something similar?
The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.
Same here. Just more thoughts, trying to spot loopholes, etc... :-)
Peter Lewis wrote:
This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about:
/snip
Just more thoughts, trying to spot loopholes, etc... :-)
The formatting got mangled. The format was The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to "insert parentheses" then let me know. Here's version 3 again without wrapping, hopefully: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
On Tuesday 07 December 2010 19:02:59 Xyne wrote:
Peter Lewis wrote:
This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds
majority for some type of serious proposal at some point... How about: /snip
Just more thoughts, trying to spot loopholes, etc... :-)
The formatting got mangled. The format was
The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition
The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to "insert parentheses" then let me know.
Ah, thought so :-)
Here's version 3 again without wrapping, hopefully:
Nice. Yeah, I don't have any better suggestion really, and apart from my general dislike for using whitespace to provide meaning (a la python) it's pretty clear to me. Actually... how about switching the sentence around somewhat:
UNLESS some other condition, the proposal is foo if EITHER A) condition 1 OR B) condition 2
is that clearer? So my only other suggestion would be that in my other post, about proposals having to have yes/no answers. Also - and this is a wider point - who should be allowed to make proposals? Only TUs, I presume... (maybe technical details just make this a moot point anyway). Pete.
As soon as I get back from lab I'm going to put the text up on a wiki page so we can stop doing massive amounts of scrolling... --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Tue, Dec 7, 2010 at 3:51 PM, Kaiting Chen <kaitocracy@gmail.com> wrote:
As soon as I get back from lab I'm going to put the text up on a wiki page so we can stop doing massive amounts of scrolling... --Kaiting.
https://wiki.archlinux.org/index.php/Bylaw_Amendment Done, Xyne's latest version can be found at above. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Wednesday 08 December 2010 01:51:52 Kaiting Chen wrote:
On Tue, Dec 7, 2010 at 3:51 PM, Kaiting Chen <kaitocracy@gmail.com> wrote:
As soon as I get back from lab I'm going to put the text up on a wiki page so we can stop doing massive amounts of scrolling... --Kaiting.
https://wiki.archlinux.org/index.php/Bylaw_Amendment
Done, Xyne's latest version can be found at above.
Nice, thanks Kaitling. I also added my line about requiring a yes/no answer, hope that's okay. I know this might seem pedantic, but I've been in situations where this wasn't specified and suddenly a proposal had like 5 options and the voting system broke. In effect, without this we rely only on the technical capabilities of the system (under the control of a few people) and I think it's better to rely on rules instead (under the control of all of us). We can always amend again if the need for multiple choice proposals arises. While reading this, one more small thing came to mind: I wonder if we should make it clear that though *the same* proposal requires a waiting period, slightly different ones don't. An example of this might be the approval of these very byelaws, where if they are voted down, a subsequent proposal might be different by just a few words. We should probably be clear about that. So I've added: "Proposals that are similar to the rejected proposal but substantively different do not require a waiting period before being presented." to the end of the waiting period paragraph. Feel free to amend for wording :-) I also think we should also tighten up the "Addition of a TU" wording, but will write about that separately. Pete.
On Wed, Dec 8, 2010 at 9:36 AM, Peter Lewis <plewis@aur.archlinux.org> wrote:
While reading this, one more small thing came to mind: I wonder if we should make it clear that though *the same* proposal requires a waiting period, slightly different ones don't. An example of this might be the approval of these very byelaws, where if they are voted down, a subsequent proposal might be different by just a few words. We should probably be clear about that.
So I've added: "Proposals that are similar to the rejected proposal but substantively different do not require a waiting period before being presented." to the end of the waiting period paragraph.
and who determines if there is a substantial difference between the two votes (I'm talking about edge cases here)? And what exactly is this substantial difference that is required, how do we quantify it? Ronald
On Wednesday 08 December 2010 12:04:22 Ronald van Haren wrote:
On Wed, Dec 8, 2010 at 9:36 AM, Peter Lewis <plewis@aur.archlinux.org> wrote:
While reading this, one more small thing came to mind: I wonder if we should make it clear that though *the same* proposal requires a waiting period, slightly different ones don't. An example of this might be the approval of these very byelaws, where if they are voted down, a subsequent proposal might be different by just a few words. We should probably be clear about that.
So I've added: "Proposals that are similar to the rejected proposal but substantively different do not require a waiting period before being presented." to the end of the waiting period paragraph.
and who determines if there is a substantial difference between the two votes (I'm talking about edge cases here)? And what exactly is this substantial difference that is required, how do we quantify it?
Indeed, there are always these questions :-) And maybe this isn't clear, but "substantive" is a little different from "substantial". It basically means that there needs to be a difference of value between the two proposals. I.e. the implication of accepting the second rather than the first would be, at least in some small way, different. That's my feeling, anyway. Pete.
On Wed, Dec 8, 2010 at 1:03 PM, Peter Lewis <plewis@aur.archlinux.org> wrote:
On Wednesday 08 December 2010 12:04:22 Ronald van Haren wrote:
On Wed, Dec 8, 2010 at 9:36 AM, Peter Lewis <plewis@aur.archlinux.org> wrote:
While reading this, one more small thing came to mind: I wonder if we should make it clear that though *the same* proposal requires a waiting period, slightly different ones don't. An example of this might be the approval of these very byelaws, where if they are voted down, a subsequent proposal might be different by just a few words. We should probably be clear about that.
So I've added: "Proposals that are similar to the rejected proposal but substantively different do not require a waiting period before being presented." to the end of the waiting period paragraph.
and who determines if there is a substantial difference between the two votes (I'm talking about edge cases here)? And what exactly is this substantial difference that is required, how do we quantify it?
Indeed, there are always these questions :-)
And maybe this isn't clear, but "substantive" is a little different from "substantial". It basically means that there needs to be a difference of value between the two proposals. I.e. the implication of accepting the second rather than the first would be, at least in some small way, different.
That's my feeling, anyway.
Pete.
I'm not a native speaker, but I always thought they could be used interchangeably. Actually most of the on-line dictionaries don't give a clear answer about the difference. Either way, we should probably try to use a different wording if the purpose is to make the document more understandable. Ronald
On Wednesday 08 December 2010 13:34:53 Ronald van Haren wrote:
and who determines if there is a substantial difference between the two votes (I'm talking about edge cases here)? And what exactly is this substantial difference that is required, how do we quantify it?
Indeed, there are always these questions :-)
And maybe this isn't clear, but "substantive" is a little different from "substantial". It basically means that there needs to be a difference of value between the two proposals. I.e. the implication of accepting the second rather than the first would be, at least in some small way, different.
That's my feeling, anyway.
I'm not a native speaker, but I always thought they could be used interchangeably. Actually most of the on-line dictionaries don't give a clear answer about the difference. Either way, we should probably try to use a different wording if the purpose is to make the document more understandable.
Sure - I'm all for easily understandable, as long as we're also precise :-) I suppose what I'm after is that the effect of the two proposals must be in some way different. It's not enough just to reword the same thing. So how about: "A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. A proposal which is similar to the rejected proposal, but whose effect is in any way different is considered a different proposal, and therefore does not require a waiting period before being presented." Pete.
On 2010-12-08 09:36 +0000 (49:3) Peter Lewis wrote:
On Wednesday 08 December 2010 01:51:52 Kaiting Chen wrote:
On Tue, Dec 7, 2010 at 3:51 PM, Kaiting Chen <kaitocracy@gmail.com> wrote:
As soon as I get back from lab I'm going to put the text up on a wiki page so we can stop doing massive amounts of scrolling... --Kaiting.
https://wiki.archlinux.org/index.php/Bylaw_Amendment
Done, Xyne's latest version can be found at above.
Nice, thanks Kaitling.
I also added my line about requiring a yes/no answer, hope that's okay. I know this might seem pedantic, but I've been in situations where this wasn't specified and suddenly a proposal had like 5 options and the voting system broke. In effect, without this we rely only on the technical capabilities of the system (under the control of a few people) and I think it's better to rely on rules instead (under the control of all of us). We can always amend again if the need for multiple choice proposals arises.
While reading this, one more small thing came to mind: I wonder if we should make it clear that though *the same* proposal requires a waiting period, slightly different ones don't. An example of this might be the approval of these very byelaws, where if they are voted down, a subsequent proposal might be different by just a few words. We should probably be clear about that.
So I've added: "Proposals that are similar to the rejected proposal but substantively different do not require a waiting period before being presented." to the end of the waiting period paragraph.
Feel free to amend for wording :-)
I also think we should also tighten up the "Addition of a TU" wording, but will write about that separately.
Pete.
I think the passage concerning "similar" proposals is too vague. There is no way to define those terms in a way that is unambiguous in all cases and trying to do so is futile and condemned to a pedantic spiral. I trust the human factor to handle those cases. People will be able to determine whether it's the same proposal or not. I've removed that passage, changed "bylaws" to "by-laws", and changed "YES / NO" to "YES or NO". As Loui pointed out, we should agree on a final version soon. I currently support this version: https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124479
On Wednesday 08 December 2010 15:23:01 Xyne wrote:
I think the passage concerning "similar" proposals is too vague. There is no way to define those terms in a way that is unambiguous in all cases and trying to do so is futile and condemned to a pedantic spiral.
I trust the human factor to handle those cases. People will be able to determine whether it's the same proposal or not.
Okay, I don't intend to push this. I just think it would be nice to avoid any ambiguity where someone says that we have to wait 3 months e.g. to amend quorum, since a proposal to do that just failed, even though the second proposal might be slightly different.
https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124479
I'm happy with that. Want to propose it then? Pete.
Peter Lewis wrote:
Okay, I don't intend to push this. I just think it would be nice to avoid any ambiguity where someone says that we have to wait 3 months e.g. to amend quorum, since a proposal to do that just failed, even though the second proposal might be slightly different.
I share your sentiment but I just don't see any practical way to objectively qualify proposals and resolve the issue. It's no wonder that there are so many poorly worded laws. They're difficult to write well and I suspect most legislators spend less time on major laws than we have on the bylaws.
https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124479
I'm happy with that. Want to propose it then?
Let's wait another day to get some more comments and incorporate any last changes. If it changes during the discussion period without unanimous consent then we would end up in a grey area when deciding which version to vote on (and we're limited by YES/NO proposals... haha).
On Wed, Dec 8, 2010 at 11:01 AM, Xyne <xyne@archlinux.ca> wrote:
Let's wait another day to get some more comments and incorporate any last changes. If it changes during the discussion period without unanimous consent then we would end up in a grey area when deciding which version to vote on (and we're limited by YES/NO proposals... haha).
I'm nitpicking here because we're pretty much at the final edit: Why do we have this redundant construct? "aur-general mailing list (aur-general)". Also I fixed one case of bylaws -> by-laws. And personally I prefer 'exceeds' to 'is greater than', and 'exceeds or equals' to 'is greater than or equal to' just for conciseness. Also I find the parts regarding the length of the discussion and voting period reading "UNLESS otherwise stated in a section of the by-laws pertaining to the proposal" rather awkward. I looked at the original bylaws and under the Standard Voting Procedure section says only "a certain period of time should be allotted to its discussion" without prescribing any length of time (it leaves the actual length of time to the sections describing each action). I would rather that this part read as the original by-laws, or that we standardize the length of the discussion period (make everything have a X day discussion period). Also if we are putting stuff like five day discussion section, seven day voting period, 66% quorum in the Standard Voting Procedure section, are we going to remove the redundant information in the other sections? As it stands now every section says 66% quorum. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Wed 08 Dec 2010 11:59 -0500, Kaiting Chen wrote:
On Wed, Dec 8, 2010 at 11:01 AM, Xyne <xyne@archlinux.ca> wrote:
Let's wait another day to get some more comments and incorporate any last changes. If it changes during the discussion period without unanimous consent then we would end up in a grey area when deciding which version to vote on (and we're limited by YES/NO proposals... haha).
Also if we are putting stuff like five day discussion section, seven day voting period, 66% quorum in the Standard Voting Procedure section, are we going to remove the redundant information in the other sections? As it stands now every section says 66% quorum. --Kaiting.
I would leave them period, but definitely leave them for at least another amendment.
On Thursday 09 December 2010 00:45:33 Loui Chang wrote:
On Wed 08 Dec 2010 11:59 -0500, Kaiting Chen wrote:
On Wed, Dec 8, 2010 at 11:01 AM, Xyne <xyne@archlinux.ca> wrote:
Let's wait another day to get some more comments and incorporate any last changes. If it changes during the discussion period without unanimous consent then we would end up in a grey area when deciding which version to vote on (and we're limited by YES/NO proposals... haha).
Also if we are putting stuff like five day discussion section, seven day voting period, 66% quorum in the Standard Voting Procedure section, are we going to remove the redundant information in the other sections? As it stands now every section says 66% quorum. --Kaiting.
I would leave them period, but definitely leave them for at least another amendment.
Indeed. In most of the democratic organisations I've worked with, we'd usually agree one thing we wanted to change, then take a look afterwards to see how / if this impacted on other things, and change them to be consistent if needed. Pete.
Kaiting Chen wrote:
I'm nitpicking here because we're pretty much at the final edit: Why do we have this redundant construct? "aur-general mailing list (aur-general)".
"aur-general" is an abbreviation of "the aur-general mailing list". I originally wrote something along the lines of "hereafter simply referred to as aur-general". It removes any ambiguity regarding what aur-general is.
Also I fixed one case of bylaws -> by-laws. And personally I prefer 'exceeds' to 'is greater than', and 'exceeds or equals' to 'is greater than or equal to' just for conciseness.
I prefer "greater|less than or equal to" in this case. I think they feel more natural.
Also I find the parts regarding the length of the discussion and voting period reading "UNLESS otherwise stated in a section of the by-laws pertaining to the proposal" rather awkward. I looked at the original bylaws and under the Standard Voting Procedure section says only "a certain period of time should be allotted to its discussion" without prescribing any length of time (it leaves the actual length of time to the sections describing each action). I would rather that this part read as the original by-laws, or that we standardize the length of the discussion period (make everything have a X day discussion period).
Also if we are putting stuff like five day discussion section, seven day voting period, 66% quorum in the Standard Voting Procedure section, are we going to remove the redundant information in the other sections? As it stands now every section says 66% quorum.
Considering that almost everything uses those defaults I think it makes more sense to keep them in one place and then simply override them as necessary elsewhere. Think of them as global variables. The rest of the by-laws should be updated to reflect the changes, both in form and substance. Loui Chang wrote:
I've removed that passage, changed "bylaws" to "by-laws", and changed "YES / NO" to "YES or NO".
I would prefer the non hyphenated spelling. *shrug*
Well, the English language disagrees with you and so does my spell-checker. :P
Xyne wrote:
Well, the English language disagrees with you and so does my spell-checker. :P
I retract that statement. Only my spell-checker disagrees. I thought I had checked it online but now I see that multiple variants are acceptable: bylaw, by-law, byelaw, bye-law. Apparently my email spell-checker agrees with all of the above except "byelaw". Bah, I trust the Collins English dictionary, which gives "bylaw" as the main entry. I've updated the text. Here is the current candidate: https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124557
On Wed 08 Dec 2010 16:23 +0100, Xyne wrote:
I think the passage concerning "similar" proposals is too vague. There is no way to define those terms in a way that is unambiguous in all cases and trying to do so is futile and condemned to a pedantic spiral.
I trust the human factor to handle those cases. People will be able to determine whether it's the same proposal or not.
I've removed that passage, changed "bylaws" to "by-laws", and changed "YES / NO" to "YES or NO".
I would prefer the non hyphenated spelling. *shrug*
As Loui pointed out, we should agree on a final version soon. I currently support this version:
https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124479
Yeah we're starting to lump too many changes into one amendment.
On Thursday 09 December 2010 00:42:20 Loui Chang wrote:
I've removed that passage, changed "bylaws" to "by-laws", and changed "YES / NO" to "YES or NO".
I would prefer the non hyphenated spelling. *shrug*
:-) ...and every time I've come across the word it's had an e in it: byelaw. *double shrug* Actually, a little light Googling shows most of the hits for "byelaw" being in the UK but most of the hits for "bylaw" being in Canada. So, I guess it depends which way you hang. Aren't words wonderful things? ;-)
On Tue 07 Dec 2010 20:27 +0000, Peter Lewis wrote:
On Tuesday 07 December 2010 19:02:59 Xyne wrote:
Peter Lewis wrote:
This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds
majority for some type of serious proposal at some point... How about: /snip
Just more thoughts, trying to spot loopholes, etc... :-)
The formatting got mangled. The format was
The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition
The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to "insert parentheses" then let me know.
Ah, thought so :-)
Here's version 3 again without wrapping, hopefully:
Nice.
Yeah, I don't have any better suggestion really, and apart from my general dislike for using whitespace to provide meaning (a la python) it's pretty clear to me.
I do like to separate words by a space and paragraphs by a blank line. It makes text easier to read and understand. ;) It's nice to see this getting some development now, but I think we should make a final revision soon, so this doesn't end up in endless discussion. It doesn't need to be perfect. Making it better than it was is good too.
On Wednesday 08 December 2010 04:33:09 Loui Chang wrote:
Yeah, I don't have any better suggestion really, and apart from my general dislike for using whitespace to provide meaning (a la python) it's pretty clear to me.
I do like to separate words by a space and paragraphs by a blank line. It makes text easier to read and understand. ;)
touché :-)
On Tuesday 07 December 2010 16:44:36 Xyne wrote:
Peter Lewis wrote:
Do we require that a proposal has only "yes" and "no" as options, as well as "abstain"? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.)
For now those are the only options available on the interface, so we don't need to consider anything else.
I agree. Let's say so then in the byelaws.
Eventually "Standard Voting Procedure" could be changed to "Simple Voting Procedure" and another procedure could be introduced for anything beyond an accept/reject motion.
Indeed :-)
In answer to your "normally" point, perhaps:
"The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws."
I tried to find a natural-sounding formulation using "unless" too but couldn't. I think it's because I already had "... nature of the proposal..." in my head. I agree with the use of "unless" but not the proposed statement.
I've used "UNLESS otherwise stated in a section of the bylaws pertaining to the proposal." in the updated version below.
Good stuff. Oops, I just saw you replied again... will reply to that...
participants (6)
-
Kaiting Chen
-
Loui Chang
-
Peter Lewis
-
Ronald van Haren
-
Thorsten Töpper
-
Xyne