Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 08/10/2013 09:15 AM, Xyne wrote: > In case anyone is wondering, the message seems to still be awaiting > moderation. This list is not activly moderated afaik. I'm just letting through your messages whenever you post about them so this discussion can go on. I'm not going to do any more moderation apart from that. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Xyne wrote: >done In case anyone is wondering, the message seems to still be awaiting moderation. I had attached the resulting docs for those who like to read plaintext. My system reported them as under 40k so I thought it would go through, but the encoding bumped it up to 42k. Sorry for the delay.
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 2013-08-09 10:26 +0200 Lukas Fleischer wrote: >+1 from me. I think you should start a new proposal. Please send this as >an inline patch, adding "[tu-bylaws]" to the subject line -- like I did. >People usually do not want to re-read the whole bylaws and exporting the >attached file just to create a diff is unnecessary work. Also, sending >an inline patch allows people for replying and adding comments to >specific sections of the patch. > >Sending the proposal as an inline patch can be easily done using > >$ git send-email --annotate HEAD^ > >after committing the changes and adding a short commit message that >summarize the changes. > >Thanks! done
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Thu, Aug 08, 2013 at 02:16:56PM +, Xyne wrote: > Lukas Fleischer wrote: > >Ok. The first idea is simple to implement: When a new proposal (the > >proposal type doesn't really matter) is created, generate a list of > >current TUs and save it. If an applicant/TU is added to the proposal, > >this user will be excluded from the list. Only users in that list are > >allowed to vote. > > By "added to the proposal", do you mean accepted as a TU? "added to the proposal" as in adding a user to the "Applicant/TU" field on the "Add Proposal" page. > > > >For the second idea, we would need to store every participant's vote. > >This has the downside that an AUR administrator could theoretically peek > >into the ballot box. > > > >Are those restrictions really necessary? What would be the downside of > >just allowing everyone with TUs powers (except the applicant/TU) to > >vote? > > If a TU resignes after the vote starts then the TU is still counted towards > quorum, and quorum may fail if the TU doesn't vote. We can always encourage > TUs > to vote before they resign, but in general I do not think that the future of > any organization should be determined by outgoing members on their way out the > door. This is not an important issue for me. I also agree that it is better > not > to associate votes with TUs, but I do not expect that to be an issue if it is > only for the duration of the vote. An AUR admin who wants to peek would modify > the code if he really wanted. Ok, agreed. > >What does this mean in practice? :) > > Let's say that the discussion period for a TU application begins and the vote > is scheduled to start on Monday. A motion is made for the removal of a TU > during this period and the vote should normally start on Tuesday. I think the > application vote should be suspended until the removal vote is finished. It > affects quorum and the outcome of the vote. > > If two removal votes are scheduled then they occur in the usual order. Sounds good. I think that this is something that doesn't need to be implemented in the AUR, though. Just a guideline for people adding proposals. > [...] > I think that's it. I have attached up updated version of my previous > submission. Take a look and let me know what you think. +1 from me. I think you should start a new proposal. Please send this as an inline patch, adding "[tu-bylaws]" to the subject line -- like I did. People usually do not want to re-read the whole bylaws and exporting the attached file just to create a diff is unnecessary work. Also, sending an inline patch allows people for replying and adding comments to specific sections of the patch. Sending the proposal as an inline patch can be easily done using $ git send-email --annotate HEAD^ after committing the changes and adding a short commit message that summarize the changes. Thanks! > > [...]
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Xyne wrote: >Lukas Fleischer wrote: > >>> The clause should probably also specify that removal votes take precedence >>> over >>> any other pending votes except removal votes. >> >>What does this mean in practice? :) > >Let's say that the discussion period for a TU application begins and the vote >is scheduled to start on Monday. A motion is made for the removal of a TU >during this period and the vote should normally start on Tuesday. I think the >application vote should be suspended until the removal vote is finished. It >affects quorum and the outcome of the vote. > >If two removal votes are scheduled then they occur in the usual order. >I think that's it. I have attached up updated version of my previous >submission. Take a look and let me know what you think. > That version does not include any mention of removal votes preceding other votes.
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Lukas Fleischer wrote: >+1. However, I would like to retain the repeated quorum offense >condition. If there are a couple of TUs that work on the AUR (as in >uploading, updating and deleting packages) and do not participate in >SVPs, they might block decisions. I think that it is important to make >sure every TU votes, especially when the new quorum comes into effect. >Maybe we should also start a removal procedure (due to undeclared >inactivity) if someone didn't participate in any of the latest SVPs, >where the start time of the first SVP and the start time of the last SVP >differ by more than two months. This could be auto-detected by the AUR. At first I didn't like this idea, but the more I think about it the more it seems to be the best solution. As long as it is done by the span of time rather than the number of votes, I think it is fair, so +1 for me. Otherwise, if we wish to stick to standard removals, we could create a page that lists all TUs who have missed one or more votes, starting from the most recent, e.g. Foo has missed 2 votes: StartEnd -mm-dd - -mm-dd -mm-dd - -mm-dd That would make it readily apparent to a human who has been skipping votes. > >> >> With the removal of the distinction between "active" and "inactive", I also >> like the idea of establishing quorum when the vote is opened. TUs who are >> added >> during the voting period (due to a parallel vote) will not be allowed to >> participate in the ongoing vote. > >> However, TU removals and resignations must be addressed. TUs who are up for >> removal must not be allowed to vote on their own removal, and maybe not on >> other votes either. TUs who resign (before the vote ends) should be removed >> from >> the quorum calculation. If they have voted, their vote should also be >> removed. >> >> For the former, a removal vote type that bars the removal candidate from >> voting >> and quorum calculations should be easy enough to implement. For >> resignations, a >> hook would be needed when a TU account is reset to a normal user account. The >> hook would simply check ongoing votes, remove the TU from the quorum list, >> and >> remove the vote if one has been cast. I don't know if the vote itself is >> stored >> in the table though, so that might require more work. If it has to be >> implemented, I would like it to be temporary. When the vote ends, the >> association of participants to their votes should be removed, an only the >> list >> of participants and the final tally should be retained. > >Ok. The first idea is simple to implement: When a new proposal (the >proposal type doesn't really matter) is created, generate a list of >current TUs and save it. If an applicant/TU is added to the proposal, >this user will be excluded from the list. Only users in that list are >allowed to vote. By "added to the proposal", do you mean accepted as a TU? >For the second idea, we would need to store every participant's vote. >This has the downside that an AUR administrator could theoretically peek >into the ballot box. > >Are those restrictions really necessary? What would be the downside of >just allowing everyone with TUs powers (except the applicant/TU) to >vote? If a TU resignes after the vote starts then the TU is still counted towards quorum, and quorum may fail if the TU doesn't vote. We can always encourage TUs to vote before they resign, but in general I do not think that the future of any organization should be determined by outgoing members on their way out the door. This is not an important issue for me. I also agree that it is better not to associate votes with TUs, but I do not expect that to be an issue if it is only for the duration of the vote. An AUR admin who wants to peek would modify the code if he really wanted. >> Some thought must be given to whether TUs who are up for removal may >> participate in other votes. With the current bylaws, any 2 TUs can remove all >> other TUs by motioning for their removal. Only those 2 TUs would be able to >> vote so they would be able to pass all the motions with 100% participation >> and >> 100% yes votes. It might be enough to modify the voting restriction to >> forbid a >> TU from voting on his or her own removal only. Perhaps we could even add some >> clause that suspends other votes until the removal vote has passed. For the >> bylaws that would require the addition of a clause to the SVP section. >> Programmatically, all new vote proposals would be blocked if a removal vote >> is >> running. > >I don't think this is needed. As you said before, restricting the TU >from voting on his or her own removal is enough. I don't think we should >make this overly complicated unless a simple solution has any real >disadvantages. Agreed. >> The clause should probably also specify that removal votes take precedence >> over >> any other pending votes except removal votes. > >What does this mean in practice? :) Let's say that the discussion
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 07, 2013 at 06:50:36PM +, Xyne wrote: > [...] > The distinction between "active" and "inactive" TUs is meaningless and should > be removed from the bylaws, including the definition of quorum. Quorum will > therefore be some fixed percent of all TUs. As stated in this thread, up to 1 > in 3 can skip the vote, and omitting "inactive" TUs defeats the purpose of > quorum. There will therefore be no need for an "active" flag on TU user > accounts on the AUR. +1. > > I still like my own suggestion for amending the removal section to add the > special case for TUs who have not touched [community], AUR or the mailing list > in 2 months. I believe that accomplishes the real goals of the current clauses > regarding unannounced inactivity and quorum blocking. All other cases in which > a TU is perceived to be avoiding his or her duties can be handled by the > standard removal procedure. +1. However, I would like to retain the repeated quorum offense condition. If there are a couple of TUs that work on the AUR (as in uploading, updating and deleting packages) and do not participate in SVPs, they might block decisions. I think that it is important to make sure every TU votes, especially when the new quorum comes into effect. Maybe we should also start a removal procedure (due to undeclared inactivity) if someone didn't participate in any of the latest SVPs, where the start time of the first SVP and the start time of the last SVP differ by more than two months. This could be auto-detected by the AUR. > > With the removal of the distinction between "active" and "inactive", I also > like the idea of establishing quorum when the vote is opened. TUs who are > added > during the voting period (due to a parallel vote) will not be allowed to > participate in the ongoing vote. Ok, agreed. > > However, TU removals and resignations must be addressed. TUs who are up for > removal must not be allowed to vote on their own removal, and maybe not on > other votes either. TUs who resign (before the vote ends) should be removed > from > the quorum calculation. If they have voted, their vote should also be removed. > > For the former, a removal vote type that bars the removal candidate from > voting > and quorum calculations should be easy enough to implement. For resignations, > a > hook would be needed when a TU account is reset to a normal user account. The > hook would simply check ongoing votes, remove the TU from the quorum list, and > remove the vote if one has been cast. I don't know if the vote itself is > stored > in the table though, so that might require more work. If it has to be > implemented, I would like it to be temporary. When the vote ends, the > association of participants to their votes should be removed, an only the list > of participants and the final tally should be retained. Ok. The first idea is simple to implement: When a new proposal (the proposal type doesn't really matter) is created, generate a list of current TUs and save it. If an applicant/TU is added to the proposal, this user will be excluded from the list. Only users in that list are allowed to vote. For the second idea, we would need to store every participant's vote. This has the downside that an AUR administrator could theoretically peek into the ballot box. Are those restrictions really necessary? What would be the downside of just allowing everyone with TUs powers (except the applicant/TU) to vote? > > Some thought must be given to whether TUs who are up for removal may > participate in other votes. With the current bylaws, any 2 TUs can remove all > other TUs by motioning for their removal. Only those 2 TUs would be able to > vote so they would be able to pass all the motions with 100% participation and > 100% yes votes. It might be enough to modify the voting restriction to forbid > a > TU from voting on his or her own removal only. Perhaps we could even add some > clause that suspends other votes until the removal vote has passed. For the > bylaws that would require the addition of a clause to the SVP section. > Programmatically, all new vote proposals would be blocked if a removal vote is > running. I don't think this is needed. As you said before, restricting the TU from voting on his or her own removal is enough. I don't think we should make this overly complicated unless a simple solution has any real disadvantages. > > The clause should probably also specify that removal votes take precedence > over > any other pending votes except removal votes. What does this mean in practice? :) > > > Regards, > Xyne Thank for for coming up with this. I like most of the suggestions. To sum up, a patch to the bylaws would (assumed that we decide for the "simple" voting restriction approach): * Change the notion of inactivity to what you suggested above. * Change the automated removal condition to inactivity for >2 months. * Make the quorum a fixed percentage of all TUs. * Exclude a TU from votes affecting
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Sébastien Luttringer wrote: >The question we have to answer is : How many TU are necessary to have >a motion pass. >Set the quorum to this value and _stop_ cheating by : >- creating more valid voters than others (the active) >- find ways to ignore the quorum is not reach (so the vote has no meaning) > >Cheers, Hi, Sorry for starting a new thread with my own proposal. I wrote it before reading through the rest of my inbox. Now that I have, I'll summarize my own suggestions, which have changed since reading through this thread, and which re-iterate the general consensus that you are already approaching. The distinction between "active" and "inactive" TUs is meaningless and should be removed from the bylaws, including the definition of quorum. Quorum will therefore be some fixed percent of all TUs. As stated in this thread, up to 1 in 3 can skip the vote, and omitting "inactive" TUs defeats the purpose of quorum. There will therefore be no need for an "active" flag on TU user accounts on the AUR. I still like my own suggestion for amending the removal section to add the special case for TUs who have not touched [community], AUR or the mailing list in 2 months. I believe that accomplishes the real goals of the current clauses regarding unannounced inactivity and quorum blocking. All other cases in which a TU is perceived to be avoiding his or her duties can be handled by the standard removal procedure. With the removal of the distinction between "active" and "inactive", I also like the idea of establishing quorum when the vote is opened. TUs who are added during the voting period (due to a parallel vote) will not be allowed to participate in the ongoing vote. However, TU removals and resignations must be addressed. TUs who are up for removal must not be allowed to vote on their own removal, and maybe not on other votes either. TUs who resign (before the vote ends) should be removed from the quorum calculation. If they have voted, their vote should also be removed. For the former, a removal vote type that bars the removal candidate from voting and quorum calculations should be easy enough to implement. For resignations, a hook would be needed when a TU account is reset to a normal user account. The hook would simply check ongoing votes, remove the TU from the quorum list, and remove the vote if one has been cast. I don't know if the vote itself is stored in the table though, so that might require more work. If it has to be implemented, I would like it to be temporary. When the vote ends, the association of participants to their votes should be removed, an only the list of participants and the final tally should be retained. Some thought must be given to whether TUs who are up for removal may participate in other votes. With the current bylaws, any 2 TUs can remove all other TUs by motioning for their removal. Only those 2 TUs would be able to vote so they would be able to pass all the motions with 100% participation and 100% yes votes. It might be enough to modify the voting restriction to forbid a TU from voting on his or her own removal only. Perhaps we could even add some clause that suspends other votes until the removal vote has passed. For the bylaws that would require the addition of a clause to the SVP section. Programmatically, all new vote proposals would be blocked if a removal vote is running. The clause should probably also specify that removal votes take precedence over any other pending votes except removal votes. Regards, Xyne p.s. you can stop CC'ing me now ;)
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 7, 2013 at 12:06 AM, Lukas Fleischer wrote: > On Wed, Aug 07, 2013 at 04:54:41AM +0800, Rashif Ray Rahman wrote: >> On 6 August 2013 20:19, Lukas Fleischer wrote: >> > On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: >> >> On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer >> >> wrote: >> >> > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: >> >> >> On 6 August 2013 05:53, Lukas Fleischer >> >> >> wrote: > The total number of TUs isn't fixed. It changes from time to time and it > might change during a SVP. I agree that it is a rare case but why not > find a proper way to handle that while we're talking about it... I do support finding a proper way to have this case handled. Between the 4 proposals, I see the 3rd as the best. Although, the discussion is public and everybody can argue, the number of voters should be finite and known at the beginning. It also simplify the vote, by having a list of allowed voters. Reading again the bylaws, I feel that we miss an important point. The SVP starts when the proposal is sent to aur-general. So to continue on the idea of the point 3, should we consider the begging of the SVP (and choosing the allowed voters) at this time or when the vote is registered in AUR? Maybe we can automate the mail sending when creating the proposal? This would enforce all deadlines and respect of the discuss and voting time. >> I think we need more opinions. Xyne? Anyway, if anyone's looking for >> some bylaw amendment history: >> https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html >> https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html >> https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html >> [...] Thanks for the references. The last one is an advanced hijack of the quorum. The question we have to answer is : How many TU are necessary to have a motion pass. Set the quorum to this value and _stop_ cheating by : - creating more valid voters than others (the active) - find ways to ignore the quorum is not reach (so the vote has no meaning) Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 7 August 2013 06:06, Lukas Fleischer wrote: > The total number of TUs isn't fixed. It changes from time to time and it > might change during a SVP. I agree that it is a rare case but why not > find a proper way to handle that while we're talking about it... OK, I was just pointing out what looked most obvious to me, in a simple way (take the static number, purposely prevent it from changing by ignoring additions/removals during the vote). > >> [...] >> * Record active at start, add newly active, ignore newly inactive, >> ignore newly added, ignore newly removed > > So we're ignoring the fact that adding/removing a TU during the SVP > distorts the results? Because it is a corner case? In that option additions/removals are not counted at all (towards quorum) -- they are exempt. You can, of course, include newly added but ignore newly removed, following the active/inactive policy. This was just a suggestion. All we need is a reasonable (read: pragmatic) system to bring new people on board to do things in their spare time, so it's fine to not take it _too_ seriously. Do whatever it takes to automate the process; the bylaws just prevent us from f*ing up at certain times. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Wed, Aug 07, 2013 at 04:54:41AM +0800, Rashif Ray Rahman wrote: > On 6 August 2013 20:19, Lukas Fleischer wrote: > > On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: > >> On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer > >> wrote: > >> > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: > >> >> On 6 August 2013 05:53, Lukas Fleischer > >> >> wrote: > >> > > >> > Any other opinions? > >> Yes, we should drop completely the active statement. > > This requires a separate proposal. Of course. We are just trying to make sure nobody raises immediate objections before submitting a new patch and restarting the whole discussion process. I will resubmit a new proposal tomorrow. > [...] > > I didn't think of it like that but I tend to agree now... Does anybody > > disagree? > > +0 The hypothetical one-TU-rules-all case has been brought up before, > but I can't cite any discussion or conclusion. It is not just the one-TU-rules-all case. As Sébastien already mentioned, establishing a quorum means that the result is representative among all eligible voters. It doesn't just mean that enough TUs who happen to be online at the right time care. > > > Anyway, we still need to find a way to count the total number of TUs. > > That number needs to be recorded at some point of time during the vote. > > The total number of TUs is a recorded statistic in the AUR, AFAICS. Or > are you referring to something else? The total number of TUs isn't fixed. It changes from time to time and it might change during a SVP. I agree that it is a rare case but why not find a proper way to handle that while we're talking about it... > [...] > * Record active at start, add newly active, ignore newly inactive, > ignore newly added, ignore newly removed So we're ignoring the fact that adding/removing a TU during the SVP distorts the results? Because it is a corner case? > > > What do you think? > > I think we need more opinions. Xyne? Anyway, if anyone's looking for > some bylaw amendment history: Agreed. Added Xyne to Cc. > > https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html > [...]
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 7 August 2013 04:54, Rashif Ray Rahman wrote: > I think we need more opinions. Xyne? Anyway, if anyone's looking for > some bylaw amendment history: > > https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html > https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html Sorry, this was somewhat off-topic to the discussion, in reference to Seblu's suggestion to drop the term 'active'. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 20:19, Lukas Fleischer wrote: > On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: >> On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer >> wrote: >> > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: >> >> On 6 August 2013 05:53, Lukas Fleischer wrote: >> > >> > Any other opinions? >> Yes, we should drop completely the active statement. This requires a separate proposal. >> This will simplify computation and restore the purpose of the quorum! >> >> "requirement for a quorum is protection against totally >> unrepresentative action in the name of the body by an unduly small >> number of persons." >> (c) Wikipedia >> >> If you think the quorum is too high, it's better to reduce it (or remove it). >> Currently it's 66%, that means 33% of voters can be in holidays, in >> hospital, in travels and don't have in a 2 weeks time frame a way to >> read some mails and vote. >> In absolute it means : 12 TUs on 36 doesn't have time to vote. >> So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. >> That means we need a bit more than 33% of the total TUs to have a >> motion pass. I'm not sure it's necessary to change this. >> >> What you suggest is automatic hijacking of the quorum, in purpose to >> reducing the number of voters. >> With the new system, we can have a motion pass with 1 voters if every >> TU goes a the next fosdem :) > > I didn't think of it like that but I tend to agree now... Does anybody > disagree? +0 The hypothetical one-TU-rules-all case has been brought up before, but I can't cite any discussion or conclusion. > Anyway, we still need to find a way to count the total number of TUs. > That number needs to be recorded at some point of time during the vote. The total number of TUs is a recorded statistic in the AUR, AFAICS. Or are you referring to something else? > Options: > > * Record at the beginning, do not update if new TUs appear. > * Record at the beginning, fix if TUs are added/removed during the SVP. > * Record at the beginning, exclude new TUs from running votes. > * Record at the end. > > The first and last option might yield bogus results. If there this one > TU when the SVP starts and another one is added during the SVP, there > might be a quorum of 2 / 1 = 200%. Same if the number is recorded at the > end and a TU is removed during the SVP. > > The second option means that we record the total number of users that > have had TU status at some point of time during the voting period. By "new" and "added", do you mean newly appointed, or newly active? This is an important distinction. If we're still talking about active/inactive and this proposal: * Record active at start, add newly active, ignore newly inactive, ignore newly added, ignore newly removed > What do you think? I think we need more opinions. Xyne? Anyway, if anyone's looking for some bylaw amendment history: https://mailman.archlinux.org/pipermail/aur-general/2007-December/000127.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012196.html https://mailman.archlinux.org/pipermail/aur-general/2010-December/012534.html > >> >> Cheers, >> >> -- >> Sébastien "Seblu" Luttringer >> https://www.seblu.net >> GPG: 0x2072D77A -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 06, 2013 at 01:12:32PM +0200, Sébastien Luttringer wrote: > On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer > wrote: > > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: > >> On 6 August 2013 05:53, Lukas Fleischer wrote: > > > > Any other opinions? > Yes, we should drop completely the active statement. > This will simplify computation and restore the purpose of the quorum! > > "requirement for a quorum is protection against totally > unrepresentative action in the name of the body by an unduly small > number of persons." > (c) Wikipedia > > If you think the quorum is too high, it's better to reduce it (or remove it). > Currently it's 66%, that means 33% of voters can be in holidays, in > hospital, in travels and don't have in a 2 weeks time frame a way to > read some mails and vote. > In absolute it means : 12 TUs on 36 doesn't have time to vote. > So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. > That means we need a bit more than 33% of the total TUs to have a > motion pass. I'm not sure it's necessary to change this. > > What you suggest is automatic hijacking of the quorum, in purpose to > reducing the number of voters. > With the new system, we can have a motion pass with 1 voters if every > TU goes a the next fosdem :) I didn't think of it like that but I tend to agree now... Does anybody disagree? Anyway, we still need to find a way to count the total number of TUs. That number needs to be recorded at some point of time during the vote. Options: * Record at the beginning, do not update if new TUs appear. * Record at the beginning, fix if TUs are added/removed during the SVP. * Record at the beginning, exclude new TUs from running votes. * Record at the end. The first and last option might yield bogus results. If there this one TU when the SVP starts and another one is added during the SVP, there might be a quorum of 2 / 1 = 200%. Same if the number is recorded at the end and a TU is removed during the SVP. The second option means that we record the total number of users that have had TU status at some point of time during the voting period. What do you think? > > Cheers, > > -- > Sébastien "Seblu" Luttringer > https://www.seblu.net > GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 6, 2013 at 11:45 AM, Lukas Fleischer wrote: > On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: >> On 6 August 2013 05:53, Lukas Fleischer wrote: > > Any other opinions? Yes, we should drop completely the active statement. This will simplify computation and restore the purpose of the quorum! "requirement for a quorum is protection against totally unrepresentative action in the name of the body by an unduly small number of persons." (c) Wikipedia If you think the quorum is too high, it's better to reduce it (or remove it). Currently it's 66%, that means 33% of voters can be in holidays, in hospital, in travels and don't have in a 2 weeks time frame a way to read some mails and vote. In absolute it means : 12 TUs on 36 doesn't have time to vote. So, to take a decision we need at least 13 voters ((36-12)/2+1) on 36 TUs. That means we need a bit more than 33% of the total TUs to have a motion pass. I'm not sure it's necessary to change this. What you suggest is automatic hijacking of the quorum, in purpose to reducing the number of voters. With the new system, we can have a motion pass with 1 voters if every TU goes a the next fosdem :) Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On Tue, Aug 06, 2013 at 08:24:20AM +0800, Rashif Ray Rahman wrote: > On 6 August 2013 05:53, Lukas Fleischer wrote: > > Instead of counting the number of active TUs when a vote begins, update > > the number whenever a TU becomes active/inactive during a voting period. > > What happens when a TU becomes inactive after casting a vote? Would > her vote be invalidated? If so, no change is needed to the bylaws. I think we shouldn't invalidate such votes. Everyone who is active and becomes inactive (or inactive and becomes active) during the voting period has to login into the AUR, click on a link in the navigation bar, uncheck a checkbox and click on a button. I don't see why they shouldn't be able to click another two links and another button :) > Otherwise, another line of explanation would help prevent ambiguity... > > > In the context of SVP, TUs are considered active if they are marked as > > active > > -when the voting period ends. > > +at some point in time during the voting period. > > In the context of SVP, TUs are considered active if they are marked as active > -when the voting period ends. > +at any point during the voting period. TUs who become inactive during the > +voting period are not considered inactive until the end of the running SVP. Sounds good to me. Any other opinions? > > > -- > GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
On 6 August 2013 05:53, Lukas Fleischer wrote: > Instead of counting the number of active TUs when a vote begins, update > the number whenever a TU becomes active/inactive during a voting period. What happens when a TU becomes inactive after casting a vote? Would her vote be invalidated? If so, no change is needed to the bylaws. Otherwise, another line of explanation would help prevent ambiguity... > In the context of SVP, TUs are considered active if they are marked as active > -when the voting period ends. > +at some point in time during the voting period. In the context of SVP, TUs are considered active if they are marked as active -when the voting period ends. +at any point during the voting period. TUs who become inactive during the +voting period are not considered inactive until the end of the running SVP. -- GPG/PGP ID: C0711BF1
[aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes
Instead of counting the number of active TUs when a vote begins, update the number whenever a TU becomes active/inactive during a voting period. This is a more accurate measure since everyone who is active at some point in time during the voting period is (technically) able to vote. Signed-off-by: Lukas Fleischer --- Rationale: The AUR soon supports automated computation of voting results. This change is needed in order to get a proper measurement for the number of active TUs. There will probably be another amendment as soon as the next AUR release is out. Let the discussion period begin! tu-bylaws.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..7d5139f 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -51,7 +51,7 @@ 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. +at some point in time during the voting period. 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 -- 1.8.4.rc1.383.g13e9f3f
