On Sun, Dec 5, 2010 at 11:33 AM, Shacristo <shacristo@gmail.com> wrote:

On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen <kaitocracy@gmail.com> wrote:

...

I move for the amendment of the bylaws. The patch against the current document is attached. Basically the amendment proposes that once an absolute majority is reached the voting period is to end immediately regardless of whether or not quorum was reached. The purpose of this amendment is to minimize parliamentary inefficiency by allowing votes with clearly decided outcomes to be resolved before the end of the established voting period. --Kaiting.

One of the stated purposes of the quorum is to "ensure that TUs remain active in the job that they have taken on." Allowing circumvention of the quorum requirements will obviously undermine that.

TU's have a lot of different responsibilities. Prolonging a decided vote by six days to motivate or ensure that someone is active does not make sense to me. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On Sun, 5 Dec 2010 12:20:06 -0500 Loui Chang <louipc.ist@gmail.com> wrote:

On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:

...

On Sun, Dec 5, 2010 at 11:33 AM, Shacristo <shacristo@gmail.com> wrote:

...

On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen <kaitocracy@gmail.com> wrote: One of the stated purposes of the quorum is to "ensure that TUs remain active in the job that they have taken on." Allowing circumvention of the quorum requirements will obviously undermine that.

TU's have a lot of different responsibilities. Prolonging a decided vote by six days to motivate or ensure that someone is active does not make sense to me. --Kaiting.

I would propose shortening the voting period then. I kind of like how the system is set up (not perfectly though) to remove the inactive TUs semi-automatically.

I agree though I'd say 5 days has to be a minimum, everyone has a couple of days when something needs to be finished and where except for getting a few runs at the build server not much of the TU stuff can be done, same goes for some days sick in bed. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On Sun, 5 Dec 2010 12:53:56 -0500 Kaiting Chen <kaitocracy@gmail.com> wrote:

On Sun, Dec 5, 2010 at 12:51 PM, Thorsten Töpper <atsutane@freethoughts.de>wrote:

...

I agree though I'd say 5 days has to be a minimum, everyone has a couple of days when something needs to be finished and where except for getting a few runs at the build server not much of the TU stuff can be done, same goes for some days sick in bed.

For falconindy's application the vote was decided in less than thirteen hours. --Kaiting.

And? Allan already brought up why this proposal is weak. Also not every- one around the world is up 24h, consider different timezones. Also the status of a vote has not to be known public till it's over so get your- self together. Shortening the voting period a bit: fine, cutting it as soon as there is something(Yes/No) does not make any sense, read the current bylaws read how inactivity is determined and then rethink about your proposal. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On 2010-12-05 12:20 -0500 (48:7) Loui Chang wrote:

On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:

...

On Sun, Dec 5, 2010 at 11:33 AM, Shacristo <shacristo@gmail.com> wrote:

...

On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen <kaitocracy@gmail.com> wrote: One of the stated purposes of the quorum is to "ensure that TUs remain active in the job that they have taken on." Allowing circumvention of the quorum requirements will obviously undermine that.

TU's have a lot of different responsibilities. Prolonging a decided vote by six days to motivate or ensure that someone is active does not make sense to me. --Kaiting.

I would propose shortening the voting period then. I kind of like how the system is set up (not perfectly though) to remove the inactive TUs semi-automatically.

I've copied my reply to another thread below for reference so you don't have to search for it (I tend to reply to messages as I read them instead of scanning everything first). After thinking about this more, I propose the following: The voting period should remain 7 days regardless of the current votes. It is rude to others to exclude them from participation even if the outcome is assured. Once the voting period is over, the motion shall pass if either an absolute majority were reached, or if a simple majority were reached with quorum. This will allow all TUs to have their say if they so choose and it sidesteps the issue of determining inactivity due to shortened voting periods while preventing motions with absolute (i.e. insurmountable) majorities from failing, which is what the real issue is here. Overall I think this is the simplest solution. Xyne wrote:

Loui Chang wrote:

...

On Sun 05 Dec 2010 08:19 -0500, Shacristo wrote:

...

On Sun, Dec 5, 2010 at 3:07 AM, Kaiting Chen <kaitocracy@gmail.com> wrote:

...

This is sort of what I was talking about in my previous mail about the refinement of the bylaws. Thirteen hours have passed since the beginning of the voting period and at this point according to this page:

https://wiki.archlinux.org/index.php/Trusted_Users

There are thirty Trusted Users. Seventeen yay's have been cast and a simple majority has already been reached. We should amend the bylaws such that the voting period may end because no amount of nay's can change the outcome of the vote at this point. There is no reason for falconindy to wait another seven days to receive his Trusted User privileges. --Kaiting.

17/30 does not make a 66% quorum, so yes, the motion could still fail.

Kaiting is saying that even though quorum hasn't been met, that it's impossible for the vote to fail on the basis of opposition.

If the rest of the TUs voted nay, then it would be 17 aye vs 13 nay which would still be a majority for the motion.

How do they do it in real life if quorum isn't met, but support for the motion is enough that it shouldn't really matter.

If quorum is required then the motion would still fail in that case.

Quorum really just prevents votes from passing with low participation, e.g. 5 participate and 3 vote yes... that would be a simple majority but clearly not enough people to carry any real weight.

We could amend the bylaws to state that quorum is not required if an absolute majority has voted to pass the motion (an absolute majority being more than half of all active TUs). I think that makes sense because as it stands now, voting against the motion or simply abstaining is completely meaningless. If one were opposed to the motion, it would be more beneficial to simply not vote at all and to hope that others do the same so that quorum cannot be established.

That actually applies in general to our application voting system. If you're against the application, it would be more effective to simply not vote, which seems wrong to me. Voting against the application should have some meaningful effect and thus be different from abstaining. I wouldn't mind having some extra clause that stipulates e.g. (#yes - #no)/#total >= x. The reasoning is that even with a simple majority, if a large portion of the team is against an application then it may be disruptive to accept it.

I realize that the argument against this will be that it isn't KISS and I'm not really bothered about it either way. I'm just floating the idea.

Btw, I actually think it would make sense to have a script that accepts the number of active TUs, and the number of votes to determine the outcome. It would be completely unambiguous and amusingly geeky. It could also be tracked with Git. ;)

Xyne wrote:

See attachment :P

Trying again...

On Sun, Dec 5, 2010 at 2:20 PM, Xyne <xyne@archlinux.ca> wrote:

Xyne wrote:

...

Xyne wrote:

...

See attachment :P

Trying again...

?

Are attachments disabled or is there something wrong on my end?

Here's the script in-line. Sorry for spamming the list.

#!/usr/bin/env python2 from sys import argv

# Quorum (66%) quorum = 0.66

# Total active TUs, yes votes, no votes, abstain votes. TUs, yes, no, abstain = [float(x) for x in argv[1:]] # Total number of votes. votes = yes + no + abstain

# If an absolute majority has voted yes, if yes / TUs > 0.50 \ # or quorum has been established with a simple majority or (votes / TUs > quorum and yes / votes > 0.50):  print "The motion has passed."

else:  print "The motion has failed."

You need to multiply 0.66 x TUs for the actual quorum requirement and you're counting no and abstain votes exactly the same. My understanding is that abstain votes are only used for establishing a quorum. Otherwise there's no reason to have them.

On Sun, Dec 5, 2010 at 2:32 PM, Xyne <xyne@archlinux.ca> wrote:

Shacristo wrote:

...

...

Here's the script in-line. Sorry for spamming the list.

#!/usr/bin/env python2 from sys import argv

# Quorum (66%) quorum = 0.66

# Total active TUs, yes votes, no votes, abstain votes. TUs, yes, no, abstain = [float(x) for x in argv[1:]] # Total number of votes. votes = yes + no + abstain

# If an absolute majority has voted yes, if yes / TUs > 0.50 \ # or quorum has been established with a simple majority or (votes / TUs > quorum and yes / votes > 0.50):  print "The motion has passed."

else:  print "The motion has failed."

You need to multiply 0.66 x TUs for the actual quorum requirement and you're counting no and abstain votes exactly the same.  My understanding is that abstain votes are only used for establishing a quorum.  Otherwise there's no reason to have them.

Um, "votes > TUs * quorum" is the same thing as "votes / TUs > quorum".

There is no difference between voting "no" and "abstain" currently. The simple majority is counted by dividing the number of "yes" votes by the total number of users that have participated, including those who "abstain".

I agree that there should be a difference between "no" and "abstain", but I didn't write the bylaws and I have proposed alternatives that would draw a distinction before, although I don't remember what.

Ah, you are correct, I missed the division there. I agree that a strict reading of the bylaws treats 'abstain' the same as 'no' despite people interpreting them to be different. Perhaps the wording should be changed now while everybody is looking over the bylaws.

On Sun 05 Dec 2010 14:23 -0500, Shacristo wrote:

On Sun, Dec 5, 2010 at 2:20 PM, Xyne <xyne@archlinux.ca> wrote:

...

Xyne wrote:

...

Xyne wrote:

...

See attachment :P

Trying again...

?

Are attachments disabled or is there something wrong on my end?

Here's the script in-line. Sorry for spamming the list.

#!/usr/bin/env python2 from sys import argv

# Quorum (66%) quorum = 0.66

# Total active TUs, yes votes, no votes, abstain votes. TUs, yes, no, abstain = [float(x) for x in argv[1:]] # Total number of votes. votes = yes + no + abstain

# If an absolute majority has voted yes, if yes / TUs > 0.50 \ # or quorum has been established with a simple majority or (votes / TUs > quorum and yes / votes > 0.50):  print "The motion has passed."

else:  print "The motion has failed."

You need to multiply 0.66 x TUs for the actual quorum requirement and you're counting no and abstain votes exactly the same. My understanding is that abstain votes are only used for establishing a quorum. Otherwise there's no reason to have them.

That's right. Abstained votes are counted for quorum (The TU was present for the vote), but is a ruined or blank vote, so do not affect the final result. The passing of the motion results from the number of 'aye' votes being greater than 'nay'.

On Sun 05 Dec 2010 19:55 +0100, Xyne wrote:

On 2010-12-05 12:20 -0500 (48:7) Loui Chang wrote:

...

On Sun 05 Dec 2010 11:53 -0500, Kaiting Chen wrote:

...

On Sun, Dec 5, 2010 at 11:33 AM, Shacristo <shacristo@gmail.com> wrote:

...

On Sun, Dec 5, 2010 at 11:16 AM, Kaiting Chen <kaitocracy@gmail.com> wrote: One of the stated purposes of the quorum is to "ensure that TUs remain active in the job that they have taken on." Allowing circumvention of the quorum requirements will obviously undermine that.

TU's have a lot of different responsibilities. Prolonging a decided vote by six days to motivate or ensure that someone is active does not make sense to me. --Kaiting.

I would propose shortening the voting period then. I kind of like how the system is set up (not perfectly though) to remove the inactive TUs semi-automatically.

I've copied my reply to another thread below for reference so you don't have to search for it (I tend to reply to messages as I read them instead of scanning everything first).

After thinking about this more, I propose the following:

The voting period should remain 7 days regardless of the current votes. It is rude to others to exclude them from participation even if the outcome is assured.

Once the voting period is over, the motion shall pass if either an absolute majority were reached, or if a simple majority were reached with quorum.

This will allow all TUs to have their say if they so choose and it sidesteps the issue of determining inactivity due to shortened voting periods while preventing motions with absolute (i.e. insurmountable) majorities from failing, which is what the real issue is here. Overall I think this is the simplest solution.

I like this solution.

PyroPeter wrote:

On 12/05/2010 07:55 PM, Xyne wrote:

...

The voting period should remain 7 days regardless of the current votes. It is rude to others to exclude them from participation even if the outcome is assured.

Once the voting period is over, the motion shall pass if either an absolute majority were reached, or if a simple majority were reached with quorum.

This will allow all TUs to have their say if they so choose and it sidesteps the issue of determining inactivity due to shortened voting periods while preventing motions with absolute (i.e. insurmountable) majorities from failing, which is what the real issue is here. Overall I think this is the simplest solution.

Maybe one could go one step further and only declare a motion as passed if there is an absolute majority after 7 days. (Meaning that more than one half of the active TUs voted YES)

This would simplify the voting procedure a lot, but would higher the barrier for a motion to pass. e.g. results that express mainly indifference with a slight tendency to YES (like 5 yes, 4 no and 15 abstain votes) would no longer pass.

I think that barrier might be a bit too high. At the same time, I think we should have some minimum barrier. As it currently stands, with Loui's and Pierre's interpretation of "abstain"*, it is fully possible for someone to become a TU with a single "yes" vote, e.g. <66% - 1> TUs abstain and only one votes "yes". It basically means "meh, I can't think of any reason *not* to give you access to [community] and the AUR, so have fun". A minimum threshold would mean "ok, enough TUs are confident that you can be trusted with access". This makes more sense to me as a TU is a *Trusted* User, not a "Not Distrusted" User. Basically, access should be given for positive reasons, not for the absence of negative reasons. Perhaps a better system would be to simply require the following two conditions to pass the votes: $yes > ($percent * $TUs) && $yes > $no In words, a set percentage of all active TUs must vote "yes" and there must be more "yes" votes than "no" notes. We could still require quorum. If quorum is not met, rather than reject the vote, it would be postponed until quorum can be met. There is no reason to reject an applicant simply because some TUs are unavailable or lazy (in which case we probably need some new TUs :P). Summarizing: * vote passes in EITHER of the following cases: - more than 50% of all active TUs vote "yes" (quorum doesn't matter in this case) - more than x% of all active TUs vote "yes" AND more vote "yes" than "no" AND quorum is established ("yes" + "no" + "abstain" > y% of all TUs) (x% and y% to be determined by discussion, e.g. 33% and 66%, resp.) * voting period never gets shortened even if the outcome is assured (others would be prevented from voting) #!/usr/bin/env python2 from sys import argv from fractions import Fraction # Threshold percentage of "yes" votes to pass motion. # 33% used only as an example. threshold = Fraction(33, 100) # Quorum (66%) quorum = Fraction(66, 100) # Majority majority = Fraction(50, 100) # Total active TUs, yes votes, no votes, abstain votes. TUs, yes, no, abstain = [Fraction(x) for x in argv[1:]] # Total number of votes. votes = yes + no + abstain # If an absolute majority has voted yes, # or quorum has been established with a simple majority if (yes / TUs) > majority \ or ( votes / TUs >= quorum and \ yes / TUs > threshold and \ yes > no \ ): print "The motion has passed." else: print "The motion has failed."

On Tue, Dec 7, 2010 at 8:16 AM, Xyne <xyne@archlinux.ca> wrote:

I think that barrier might be a bit too high. At the same time, I think we should have some minimum barrier. As it currently stands, with Loui's and Pierre's interpretation of "abstain"*, it is fully possible for someone to become a TU with a single "yes" vote, e.g. <66% - 1> TUs abstain and only one votes "yes".

Democracy dies in apathy. The abstain vote should be used sparingly in the case where a TU has not had time determine the full state of the application. I think in all other cases having an opinion is an important responsibility for a Trusted User. In the end I think the current system is complicated enough as it is. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/