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] Remove lib32-catalyst-test-utils
On 6 August 2013 15:32, Jameson wrote: > Please, remove lib32-catalyst-test-utils. I've created > lib32-catalyst-utils-test in order to match the naming scheme of the > 64-bit version. > > Thanks, > =-Jameson Merged. Please provide links next time. Thx, Lukas
[aur-general] Remove lib32-catalyst-test-utils
Please, remove lib32-catalyst-test-utils. I've created lib32-catalyst-utils-test in order to match the naming scheme of the 64-bit version. Thanks, =-Jameson
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
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 12 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 12 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (12 total) == * bbswitch-0.7-8 (i686) * r8168-8.036.00-5 (i686) * rt3562sta-2.4.1.1-38 (i686) * tp_smapi-0.41-29 (i686) * vhba-module-20130607-8 (i686) * virtualbox-modules-4.2.16-5 (i686) * bbswitch-0.7-8 (x86_64) * r8168-8.036.00-5 (x86_64) * rt3562sta-2.4.1.1-38 (x86_64) * tp_smapi-0.41-29 (x86_64) * vhba-module-20130607-8 (x86_64) * virtualbox-modules-4.2.16-5 (x86_64) == Incomplete signoffs for [community] (12 total) == * bbswitch-0.7-8 (i686) 0/1 signoffs * r8168-8.036.00-5 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-38 (i686) 0/1 signoffs * tp_smapi-0.41-29 (i686) 0/1 signoffs * vhba-module-20130607-8 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-5 (i686) 0/1 signoffs * bbswitch-0.7-8 (x86_64) 0/2 signoffs * r8168-8.036.00-5 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-38 (x86_64) 0/2 signoffs * tp_smapi-0.41-29 (x86_64) 0/2 signoffs * vhba-module-20130607-8 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-5 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. foutrelis - 4 signoffs 2. bpiotrowski - 3 signoffs
