[aur-general] [tu-bylaws] [PATCH] add README describing how to update the bylaws
Signed-off-by: Eli Schwartz
---
This is not an amendment to the bylaws themselves, and as such does not
require any sort of vote. But I think this is rather useful to have, as
there is currently not a case of perfect clarity for the administrivium
involved in processing updates. As development of the bylaws happens on
this list, I'm sending it in here. Hope this change makes sense to all.
README.md | 12
1 file changed, 12 insertions(+)
create mode 100644 README.md
diff --git a/README.md b/README.md
new file mode 100644
index 000..262a22c
--- /dev/null
+++ b/README.md
@@ -0,0 +1,12 @@
+# AUR Trusted User Bylaws
+
+This document describes the bylaws which govern the Arch Linux Trusted Users.
+
+Instructions for updating:
+
+- follow the procedure outlined in the bylaws for proposing an update
+- if accepted, push to master branch of this repository and tag the commit
+ "proposal-$num" to correspond with the vote ID at
+ https://aur.archlinux.org/tu/
+- ask one of the aurweb maintainers to run `make` and deploy the resulting
+ `*.html` to `${aurweb_root}/web/html/trusted-user/`
--
2.20.1
Re: [aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 14 days
The discussion period is over, lets give the reviewers and applicants some more time :] https://aur.archlinux.org/tu/?id=109 cheers, Levente signature.asc Description: OpenPGP digital signature
[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 14 days
I quite definitively should not send patches when being incredibly tired, of cause the subject should be "14 days" matching what the body actually describes and changes. I'm sorry >.> Levente signature.asc Description: OpenPGP digital signature
[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 7 days
Just adding this signed mail to authenticate i indeed proposed this change :) cheers, Levente signature.asc Description: OpenPGP digital signature
[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 7 days
From: anthraxx Signed-off-by: Levente Polyak --- The discussion period for the addition of a new TU is too short. After having some chats on this topic with multiple TUs it seemed like a general consensus to extended the dicussion period to 14 days, hence this proposal. 5 days are rarely enough to discuss all details with the applicant taking into account that f.e. lots of packages need to be reviewed. Once feedback was given to the applicant there shall be enough time to work through it, potentially research, apply and/or discuss things out of the feedback. Given the fact that many people, including the applicant, may be in the middle of a work week (or otherwise busy), having only 5 days to do one or multiple feedback loops is unrealistic and too much pressure. Considering the fact that it is an essential part for a TU to be able to decide on the vote as well as for the applicant to have enough time and the possibility to respond properly to the input an adjusted discussion period of 14 days shall be appropriate. --- tu-bylaws.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 27e4804..d32e06c 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -104,10 +104,10 @@ In order to become a TU, one must first find a sponsoring TU, and arrange privately with them to announce their candidacy on the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] mailing list. Following the announcement, standard voting procedure commences with a -discussion period of 5 days, a quorum of 66%, and a voting period of 7 days. +discussion period of 14 days, a quorum of 66%, and a voting period of 7 days. -SVP( addition_of_TU, 5, 0.66, 7 ); +SVP( addition_of_TU, 14, 0.66, 7 ); If a candidate is rejected by SVP, they may not reapply to become a Trusted -- 2.18.0
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 01/24/2018 11:18 AM, Eli Schwartz wrote: > On 01/23/2018 12:54 PM, Eli Schwartz wrote: >> On 01/18/2018 06:18 PM, Eli Schwartz wrote: >>> Not everything that is available only to an aurweb account of the >>> Trusted User type, qualifies as a TU "privilege" >>> >>> Signed-off-by: Eli Schwartz >>> --- >>> >>> Handy link to context and surrounding discussion: >>> >>> https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html >>> >>> The current wording of the bylaws indicates that there are two ways for >>> a TU to qualify for special removal due to inactivity: >>> >>> 1) Do not participate in voting, thereby potentially blockading a quorum. >>> >>> 2) Do not participate in general TU'ish activities like maintaining >>>[community], administrating the AUR and the packagers and users therein, >>>being representative of TUs in general on this mailing list by being >>>awesome and stuff, i.e. posting (hopefully useful information that helps >>>AUR users), and... um... voting? >>> >>> Point #2 calls out "performed any action that required TU privileges on >>> the AUR", but does the tu voting interface on aurweb count as that or >>> not? Moreover, do we *want* it to count? It seems to be somewhat >>> defeating the purpose of the process, i.e. as long as a TU doesn't >>> actually block quorum during a vote, they can remain while not actually >>> performing any of the inherent functions of a TU. >>> >>> Now, I would argue that under a common sense interpretation the original >>> intent of the bylaws was almost certainly that voting does not count as >>> a "TU privilege", since a TU is someone who has the "privilege" to >>> administrate AUR packages and users in order to keep good order, and >>> select good packages to upload to [community]. >>> >>> But bylaws exist in order to prevent people from having different >>> interpretations of common sense. So this should be clarified no matter >>> what. >> >> Thus far, we've (I think) only seen people argue that: >> >> 1) this is what the bylaws really mean, let us clarify it for the sake >> of less confusion some other day, >> >> 2) The bylaws do not mean this and should not do this. >> >> >> Can I assume that means there is no one who feels this *should* be true, >> but currently *isn't*? >> >> ... >> >> Does anyone have any last-minute proposals to modify the wording for >> grammar etc. in the event that this is accepted? > > The discussion period is over, time to vote! > > https://aur.archlinux.org/tu/?id=102 The results are in! Yes No Abstain Total Voted Participation 26 9 4 39Yes 81.25% Seems like overall people thought this was a reasonable interpretation. Rather than holding *another* round of votes to decide whether the previous voting results (for #100 and #101) should be upheld two weeks later, I think it is safe to declare that the previous proposals were indeed valid. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 01/23/2018 12:54 PM, Eli Schwartz wrote: > On 01/18/2018 06:18 PM, Eli Schwartz wrote: >> Not everything that is available only to an aurweb account of the >> Trusted User type, qualifies as a TU "privilege" >> >> Signed-off-by: Eli Schwartz >> --- >> >> Handy link to context and surrounding discussion: >> >> https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html >> >> The current wording of the bylaws indicates that there are two ways for >> a TU to qualify for special removal due to inactivity: >> >> 1) Do not participate in voting, thereby potentially blockading a quorum. >> >> 2) Do not participate in general TU'ish activities like maintaining >>[community], administrating the AUR and the packagers and users therein, >>being representative of TUs in general on this mailing list by being >>awesome and stuff, i.e. posting (hopefully useful information that helps >>AUR users), and... um... voting? >> >> Point #2 calls out "performed any action that required TU privileges on >> the AUR", but does the tu voting interface on aurweb count as that or >> not? Moreover, do we *want* it to count? It seems to be somewhat >> defeating the purpose of the process, i.e. as long as a TU doesn't >> actually block quorum during a vote, they can remain while not actually >> performing any of the inherent functions of a TU. >> >> Now, I would argue that under a common sense interpretation the original >> intent of the bylaws was almost certainly that voting does not count as >> a "TU privilege", since a TU is someone who has the "privilege" to >> administrate AUR packages and users in order to keep good order, and >> select good packages to upload to [community]. >> >> But bylaws exist in order to prevent people from having different >> interpretations of common sense. So this should be clarified no matter >> what. > > Thus far, we've (I think) only seen people argue that: > > 1) this is what the bylaws really mean, let us clarify it for the sake > of less confusion some other day, > > 2) The bylaws do not mean this and should not do this. > > > Can I assume that means there is no one who feels this *should* be true, > but currently *isn't*? > > ... > > Does anyone have any last-minute proposals to modify the wording for > grammar etc. in the event that this is accepted? The discussion period is over, time to vote! https://aur.archlinux.org/tu/?id=102 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 01/23/2018 02:16 PM, Balló György via aur-general wrote: >> Does anyone have any last-minute proposals to modify the wording for >> grammar etc. in the event that this is accepted? > > Sounds good for me. But how can we check if a TU modify a user account > or do anything other than resolving package requests (which is tracked > on aur-requests mailing list)? Currently these actions are untracked on > aurweb, so we don't really know the last action. I think we need a > 'last privileged action' field or 'privileged action log' or something > similar to be implemented in aurweb, so any TU could easily check if > the condition met or not. We probably do need some way to track non-requests package deletions, use of AUR_PRIVILEGED in the git backend, etc. But I will probably defer to Lukas/Johannes for that, it sounds like it would involve php. It's not like we were keeping track of this as we should up to now, so that wouldn't really change. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
> Does anyone have any last-minute proposals to modify the wording for > grammar etc. in the event that this is accepted? Sounds good for me. But how can we check if a TU modify a user account or do anything other than resolving package requests (which is tracked on aur-requests mailing list)? Currently these actions are untracked on aurweb, so we don't really know the last action. I think we need a 'last privileged action' field or 'privileged action log' or something similar to be implemented in aurweb, so any TU could easily check if the condition met or not. -- György Balló Trusted User signature.asc Description: This is a digitally signed message part
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 01/18/2018 06:18 PM, Eli Schwartz wrote: > Not everything that is available only to an aurweb account of the > Trusted User type, qualifies as a TU "privilege" > > Signed-off-by: Eli Schwartz > --- > > Handy link to context and surrounding discussion: > > https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html > > The current wording of the bylaws indicates that there are two ways for > a TU to qualify for special removal due to inactivity: > > 1) Do not participate in voting, thereby potentially blockading a quorum. > > 2) Do not participate in general TU'ish activities like maintaining >[community], administrating the AUR and the packagers and users therein, >being representative of TUs in general on this mailing list by being >awesome and stuff, i.e. posting (hopefully useful information that helps >AUR users), and... um... voting? > > Point #2 calls out "performed any action that required TU privileges on > the AUR", but does the tu voting interface on aurweb count as that or > not? Moreover, do we *want* it to count? It seems to be somewhat > defeating the purpose of the process, i.e. as long as a TU doesn't > actually block quorum during a vote, they can remain while not actually > performing any of the inherent functions of a TU. > > Now, I would argue that under a common sense interpretation the original > intent of the bylaws was almost certainly that voting does not count as > a "TU privilege", since a TU is someone who has the "privilege" to > administrate AUR packages and users in order to keep good order, and > select good packages to upload to [community]. > > But bylaws exist in order to prevent people from having different > interpretations of common sense. So this should be clarified no matter > what. Thus far, we've (I think) only seen people argue that: 1) this is what the bylaws really mean, let us clarify it for the sake of less confusion some other day, 2) The bylaws do not mean this and should not do this. Can I assume that means there is no one who feels this *should* be true, but currently *isn't*? ... Does anyone have any last-minute proposals to modify the wording for grammar etc. in the event that this is accepted? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 01/21/2018 04:19 PM, Lukas Fleischer via aur-general wrote: > On Sun, 21 Jan 2018 at 21:40:43, Xyne wrote: >> On 2018-01-21 10:04 +0100 >> Lukas Fleischer via aur-general wrote: >> >>> So you suggest to remove the first part of the condition (before the >>> "OR") altogether? >> >> I made no such suggestion. > > By your logic, there is no situation where the first part of the > condition applies but the second part (after the "OR") does not. So we > could as well remove the part before the "OR" -- and, if that were the > case, we would have removed the statement before the amendment of the > bylaws. > > If what I am saying is not true, there might be a misunderstanding: in > this case, please describe a situation where only the part before the > "OR" applies but the part after the "OR" does not. Well, strictly speaking in the event that there have been no prospective votes in more than two months, but the TU in question did vote for the votes from, say, three and four months ago but then dropped off the face of the community for the last two months, they would qualify for special removal under the part before the OR, but not the part after the OR. I think that having to contrive that circumstance indicates that it is, in fact, contrived and going against the intent. > In fact, even if you really want to be pedantic and take everything in > the bylaws literally, the first condition before the "OR" applies if a > Trusted User does nothing but vote: in today's terminology, the "AUR" is > the "Arch User Repository" (the collection of packages uploaded and > maintained by users) and the web interface is called "aurweb", see [1]. > So, while voting is a TU action performed in aurweb, it is clearly not > "any action that required TU privileges on the AUR" because the AUR > (package collection) is not touched. Indeed! I tried to make this evident in my initial proposal to this thread. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On Sun, 21 Jan 2018 at 21:40:43, Xyne wrote: > On 2018-01-21 10:04 +0100 > Lukas Fleischer via aur-general wrote: > > >So you suggest to remove the first part of the condition (before the > >"OR") altogether? > > I made no such suggestion. By your logic, there is no situation where the first part of the condition applies but the second part (after the "OR") does not. So we could as well remove the part before the "OR" -- and, if that were the case, we would have removed the statement before the amendment of the bylaws. If what I am saying is not true, there might be a misunderstanding: in this case, please describe a situation where only the part before the "OR" applies but the part after the "OR" does not. > And again, the intention of the current bylaws was not to disregard voting as > an activity. The first part was to speed up the process for TUs who show no > visible online activity (i.e. TUs who have abandoned Arch completely, for > whatever reason), and the second part was to remove those who prevent the > establishment of quorum. A TU who votes is clearly still logging in to his or > her account and not preventing quorum. So yeah, a TU who does nothing but vote > for over a year should be removed, but by a regular removal process, which the > bylaws already handle. Makes no sense. See above. We would not have listed all the details of what TU inactivity means if inactivity always implies the part after the "OR". > > Btw, we discussed this together over 4 years ago and we were in agreement then > about both the intention and the formulation. Here's a message in which you > clearly agreed with this intention: > > https://lists.archlinux.org/pipermail/aur-general/2013-August/024783.html I did agree that inactivity should be a sufficient condition for special removal. I did never agree that inactivity requires not voting. In that email, I even explained that I understand "work on the AUR" as "uploading, updating and deleting packages". In fact, even if you really want to be pedantic and take everything in the bylaws literally, the first condition before the "OR" applies if a Trusted User does nothing but vote: in today's terminology, the "AUR" is the "Arch User Repository" (the collection of packages uploaded and maintained by users) and the web interface is called "aurweb", see [1]. So, while voting is a TU action performed in aurweb, it is clearly not "any action that required TU privileges on the AUR" because the AUR (package collection) is not touched. Regards, Lukas [1] https://git.archlinux.org/aurweb.git/plain/README
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 2018-01-21 10:04 +0100 Lukas Fleischer via aur-general wrote: >So you suggest to remove the first part of the condition (before the >"OR") altogether? I made no such suggestion. With the current bylaws, any 2 TUs can start a regular removal process for any reason. This suffices to remove TUs who aren't "doing enough" according to the majority of other TUs. The only difference from the special removal process is a few more days and a higher quorum. The current bylaws are explicit and fine as they are. There is no need to change them. A TU who still shows signs of recent online activity should be given the full discussion period of a regular removal process to offer an explanation or resignation. After all, all TUs have contributed to this community and were recruited due to qualities that we recognized in them at the time of their application. A few extra days to hear their them out before kicking them out is a costless courtesy. Unless they are preventing quorum from being established, there is absolutely no harm nor pressing need to speed up the process. Just to be clear, I support the proposed removals given the cited inactivity, and I agree that doing nothing other than vote for over a year is not the intended mission of a TU. The silence from both during the discussion period is also strange given that they still log in to vote (vote timers?). And again, the intention of the current bylaws was not to disregard voting as an activity. The first part was to speed up the process for TUs who show no visible online activity (i.e. TUs who have abandoned Arch completely, for whatever reason), and the second part was to remove those who prevent the establishment of quorum. A TU who votes is clearly still logging in to his or her account and not preventing quorum. So yeah, a TU who does nothing but vote for over a year should be removed, but by a regular removal process, which the bylaws already handle. Btw, we discussed this together over 4 years ago and we were in agreement then about both the intention and the formulation. Here's a message in which you clearly agreed with this intention: https://lists.archlinux.org/pipermail/aur-general/2013-August/024783.html You later approved my patch. Regards, Xyne
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On Sun, 21 Jan 2018 at 04:24:49, Xyne wrote: > > The intent of the first sectionm before the "OR", is to measure any sort of > > activity. Updating a package, voting or posting a comment shows that the TU > > is still logging in to the AUR and thus active in some sense. The point of > > the first section was to provide a way to remove TUs who had simply > > disappeared. This is as it should be. There is no mandated TU quota for > > package actions. > > > The intent of the second section, after the "OR", is to ensure that TUs who > > repeatedly disregard votes and possibly prevent quorum from being > > established > > can be removed. > > The special removal procedure was only added to handle special cases where the > TU has clearly abandoned Arch altogether (no detectable activity in the last > two months) or the TU has simply ignored votes and thus jeopardized quorum, > again over a period of two months or more. > > The normal procedure should be used to remove a TU who has not impeded other > TUs in their mission and who has been active within the last two months, which > gives them time to offer an explanation or a resignation. So you suggest to remove the first part of the condition (before the "OR") altogether?
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 2018-01-19 09:16 +0100 Lukas Jirkovsky via aur-general wrote: >My common sense tells me that activity that helps Arch Linux to >prosper should be considered – be it packaging, triaging AUR requests >etc. > >From that point of view, it makes sense to not count voting as TU >activity, thereby blocking the potential removal. > >Just my 2 cents. > >Lukas I oppose this patch and will vote against for the reasons given in my previous reply on this list, which I repost here: > The intent of the first sectionm before the "OR", is to measure any sort of > activity. Updating a package, voting or posting a comment shows that the TU > is still logging in to the AUR and thus active in some sense. The point of > the first section was to provide a way to remove TUs who had simply > disappeared. This is as it should be. There is no mandated TU quota for > package actions. > The intent of the second section, after the "OR", is to ensure that TUs who > repeatedly disregard votes and possibly prevent quorum from being established > can be removed. The special removal procedure was only added to handle special cases where the TU has clearly abandoned Arch altogether (no detectable activity in the last two months) or the TU has simply ignored votes and thus jeopardized quorum, again over a period of two months or more. The normal procedure should be used to remove a TU who has not impeded other TUs in their mission and who has been active within the last two months, which gives them time to offer an explanation or a resignation. Regards, Xyne
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On Thu, Jan 18, 2018 at 06:18:11PM -0500, Eli Schwartz via aur-general wrote: > +2. performed any action that required TU privileges on the AUR, for example > +resolving package requests, modifying user accounts, or force pushing to a > +package base, but NOT including participation in a voting period I'm not a TU, but can I suggest replacing "for example" with "such as"? "such as... but not including" sounds nicer. -- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth ext: 4539 signature.asc Description: PGP signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On 19 January 2018 at 00:18, Eli Schwartz via aur-general wrote: > Not everything that is available only to an aurweb account of the > Trusted User type, qualifies as a TU "privilege" > > Signed-off-by: Eli Schwartz > --- > > Handy link to context and surrounding discussion: > > https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html > > The current wording of the bylaws indicates that there are two ways for > a TU to qualify for special removal due to inactivity: > > 1) Do not participate in voting, thereby potentially blockading a quorum. > > 2) Do not participate in general TU'ish activities like maintaining >[community], administrating the AUR and the packagers and users therein, >being representative of TUs in general on this mailing list by being >awesome and stuff, i.e. posting (hopefully useful information that helps >AUR users), and... um... voting? > > Point #2 calls out "performed any action that required TU privileges on > the AUR", but does the tu voting interface on aurweb count as that or > not? Moreover, do we *want* it to count? It seems to be somewhat > defeating the purpose of the process, i.e. as long as a TU doesn't > actually block quorum during a vote, they can remain while not actually > performing any of the inherent functions of a TU. > > Now, I would argue that under a common sense interpretation the original > intent of the bylaws was almost certainly that voting does not count as > a "TU privilege", since a TU is someone who has the "privilege" to > administrate AUR packages and users in order to keep good order, and > select good packages to upload to [community]. > > But bylaws exist in order to prevent people from having different > interpretations of common sense. So this should be clarified no matter > what. > > > tu-bylaws.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/tu-bylaws.txt b/tu-bylaws.txt > index c7a376e..27e4804 100644 > --- a/tu-bylaws.txt > +++ b/tu-bylaws.txt > @@ -142,7 +142,9 @@ A TU who has not done ANY of the following for a period > of at least 2 months: > > 1. added, removed or updated a package in +[community]+ or the AUR > > -2. performed any action that required TU privileges on the AUR > +2. performed any action that required TU privileges on the AUR, for example > +resolving package requests, modifying user accounts, or force pushing to a > +package base, but NOT including participation in a voting period > > 3. posted a message to > https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] > > -- > 2.16.0 My common sense tells me that activity that helps Arch Linux to prosper should be considered – be it packaging, triaging AUR requests etc. >From that point of view, it makes sense to not count voting as TU activity, thereby blocking the potential removal. Just my 2 cents. Lukas
[aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
Not everything that is available only to an aurweb account of the Trusted User type, qualifies as a TU "privilege" Signed-off-by: Eli Schwartz --- Handy link to context and surrounding discussion: https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html The current wording of the bylaws indicates that there are two ways for a TU to qualify for special removal due to inactivity: 1) Do not participate in voting, thereby potentially blockading a quorum. 2) Do not participate in general TU'ish activities like maintaining [community], administrating the AUR and the packagers and users therein, being representative of TUs in general on this mailing list by being awesome and stuff, i.e. posting (hopefully useful information that helps AUR users), and... um... voting? Point #2 calls out "performed any action that required TU privileges on the AUR", but does the tu voting interface on aurweb count as that or not? Moreover, do we *want* it to count? It seems to be somewhat defeating the purpose of the process, i.e. as long as a TU doesn't actually block quorum during a vote, they can remain while not actually performing any of the inherent functions of a TU. Now, I would argue that under a common sense interpretation the original intent of the bylaws was almost certainly that voting does not count as a "TU privilege", since a TU is someone who has the "privilege" to administrate AUR packages and users in order to keep good order, and select good packages to upload to [community]. But bylaws exist in order to prevent people from having different interpretations of common sense. So this should be clarified no matter what. tu-bylaws.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index c7a376e..27e4804 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -142,7 +142,9 @@ A TU who has not done ANY of the following for a period of at least 2 months: 1. added, removed or updated a package in +[community]+ or the AUR -2. performed any action that required TU privileges on the AUR +2. performed any action that required TU privileges on the AUR, for example +resolving package requests, modifying user accounts, or force pushing to a +package base, but NOT including participation in a voting period 3. posted a message to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] -- 2.16.0
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
The proposed changes have been accepted. Final tally: yes: 27 no: 0 abstain: 4
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 05:45:50PM +0200, Lukas Fleischer wrote: > On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: > > On 2013-08-20 18:14 +0200 > > Lukas Fleischer wrote: > > > > >+SVP is commenced at the time of the motion, with a discussion period of 5 > > >days, > > >+a quorum of 75%, and a voting period of 7 days. > > > > > > Use the same formulation as the "Removal of a TU" section: > > >Following the motion, standard voting procedure commences with a discussion > > >period of 5 days, a quorum of 75%, and a voting period of 7 days. > > > > You can also replace "standard voting procedure" with "SVP" throughout the > > document after its definition. > > Note that I did not touch this sentence apart from formatting changes. > > > > > >+be sent "inline" (i.e. using `git send-email`) so that other TUs can > > >easily > > > > I would change "i.e." to "e.g." as I see no reason to mandate that users > > actually send the message with git directly (as this requires sendmail > > configuration, and some users may only have access to webmail). The > > formatting > > of the message itself is what matters. > > Git does not require sendmail. It requires an MTA but something simple > and lightweight like msmtp(1) does the job. It takes about 5 minutes to > setup. It doesn't even require an MTA. git is able to send directly to an SMTP server via the perl script that manages mail. See the --smtp-* options in 'git-send-email(1)'. Specifically, the --smtp-server option defaults to 'localhost' which means that it defaults to using a locally found MTA. > Around 90% of all patches that are sent by Git rookie without using `git > send-email` are broken in some way. Most common errors are: > > * Wrong patch format. Patches created with diff(1) or something else. > > * Patch is not sent inline. This makes it damn hard to comment on > specific parts. > > * Broken indentation and line wraps. This often happens when patches are > sent using webmail. Webmail should never be used to send patches > unless you know exactly what you are doing. > > When applying your patch, I had to export your proposal mail to an mbox > file, edit that mbox file and remove the parts that do not belong to the > patch, save the resulting file and apply it using `git am`. This is why > I came up with this... If there is a generally accepted format which is > very convenient, why not use it? > > Also, the document says "should be sent" -- not "must be sent". Everyone > who knows what he/she is doing can send the patch using another tool and > hardly anyone will notice. > > > > > To be honest, I don't see the problem with accepting the resulting document > > either. Copying over a single document is no more work than applying a > > patch. > > 1. Most people want to see a diff. Hardly anyone wants to read the whole >document over and over again and scan for minor wording changes every >time. Sending a document means that every TU has to clone the >tu-bylaws Git repository, save the attachment, copy it to the working >directory of the clone and invoke `git diff`. Why? > > 2. Attaching a document makes it a lot harder to comment on specific >parts by using the "quote" function of the mail client, like you did >when replying to my patch :) > > 3. The committer will have to write a commit message and adjust the >author's e-mail address (and maybe also change the author date). > > > > > Perhaps we could also add an additional minor change to this patchset to say > > that the SVP voting period ends either after the designated time OR after > > all > > TUs have voted. With the upcoming changes to the AUR this will be apparent, > > and > > the AUR can stop the vote itself an possibly send an email to the list. > > Ok, I can add this. But I doubt that there will ever be such a > situation. Did we ever have a voting with a participation of 100%? :) > > > > >
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: > On 2013-08-20 18:14 +0200 > Lukas Fleischer wrote: > > >+SVP is commenced at the time of the motion, with a discussion period of 5 > >days, > >+a quorum of 75%, and a voting period of 7 days. > > > Use the same formulation as the "Removal of a TU" section: > >Following the motion, standard voting procedure commences with a discussion > >period of 5 days, a quorum of 75%, and a voting period of 7 days. > > You can also replace "standard voting procedure" with "SVP" throughout the > document after its definition. Note that I did not touch this sentence apart from formatting changes. > > >+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily > > I would change "i.e." to "e.g." as I see no reason to mandate that users > actually send the message with git directly (as this requires sendmail > configuration, and some users may only have access to webmail). The formatting > of the message itself is what matters. Git does not require sendmail. It requires an MTA but something simple and lightweight like msmtp(1) does the job. It takes about 5 minutes to setup. Around 90% of all patches that are sent by Git rookie without using `git send-email` are broken in some way. Most common errors are: * Wrong patch format. Patches created with diff(1) or something else. * Patch is not sent inline. This makes it damn hard to comment on specific parts. * Broken indentation and line wraps. This often happens when patches are sent using webmail. Webmail should never be used to send patches unless you know exactly what you are doing. When applying your patch, I had to export your proposal mail to an mbox file, edit that mbox file and remove the parts that do not belong to the patch, save the resulting file and apply it using `git am`. This is why I came up with this... If there is a generally accepted format which is very convenient, why not use it? Also, the document says "should be sent" -- not "must be sent". Everyone who knows what he/she is doing can send the patch using another tool and hardly anyone will notice. > > To be honest, I don't see the problem with accepting the resulting document > either. Copying over a single document is no more work than applying a patch. 1. Most people want to see a diff. Hardly anyone wants to read the whole document over and over again and scan for minor wording changes every time. Sending a document means that every TU has to clone the tu-bylaws Git repository, save the attachment, copy it to the working directory of the clone and invoke `git diff`. Why? 2. Attaching a document makes it a lot harder to comment on specific parts by using the "quote" function of the mail client, like you did when replying to my patch :) 3. The committer will have to write a commit message and adjust the author's e-mail address (and maybe also change the author date). > > Perhaps we could also add an additional minor change to this patchset to say > that the SVP voting period ends either after the designated time OR after all > TUs have voted. With the upcoming changes to the AUR this will be apparent, > and > the AUR can stop the vote itself an possibly send an email to the list. Ok, I can add this. But I doubt that there will ever be such a situation. Did we ever have a voting with a participation of 100%? :) > >
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On 2013-08-20 18:14 +0200 Lukas Fleischer wrote: >+SVP is commenced at the time of the motion, with a discussion period of 5 >days, >+a quorum of 75%, and a voting period of 7 days. Use the same formulation as the "Removal of a TU" section: >Following the motion, standard voting procedure commences with a discussion >period of 5 days, a quorum of 75%, and a voting period of 7 days. You can also replace "standard voting procedure" with "SVP" throughout the document after its definition. >+be sent "inline" (i.e. using `git send-email`) so that other TUs can easily I would change "i.e." to "e.g." as I see no reason to mandate that users actually send the message with git directly (as this requires sendmail configuration, and some users may only have access to webmail). The formatting of the message itself is what matters. To be honest, I don't see the problem with accepting the resulting document either. Copying over a single document is no more work than applying a patch. Perhaps we could also add an additional minor change to this patchset to say that the SVP voting period ends either after the designated time OR after all TUs have voted. With the upcoming changes to the AUR this will be apparent, and the AUR can stop the vote itself an possibly send an email to the list.
[aur-general] [tu-bylaws] [PATCH 1/2] Add note on when the number of TUs is recorded
The quorum section does not mention when the number of TUs is recorded. Add a note that this is done at the beginning of the voting period. This makes it easy to implement automated quorum calculation in the AUR. Signed-off-by: Lukas Fleischer --- tu-bylaws.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 4e8c5e2..2faecda 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -92,7 +92,8 @@ discussions whenever possible. Quorum shall be 66% of all 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 bylaws pertaining to the proposal. The total number of TUs is recorded at +the beginning of the voting period. Addition of a TU -- 1.8.4.rc3.500.gc3113b0
[aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
* Mention the tu-bylaws.git repository. * Mention Git-formatted patches and subject keywords. * Promote `git send-email`. * Add note on submitting several patches at once. Signed-off-by: Lukas Fleischer --- tu-bylaws.txt | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 2faecda..c7a376e 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -165,10 +165,25 @@ These bylaws may be amended at any time. A TU must motion for an amendment by sending an announcement to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. -The message must either contain, or have attached, a patch against this -document which accomplishes the suggested change. SVP is commenced at the time -of the motion, with a discussion period of 5 days, a quorum of 75%, and a -voting period of 7 days. + +The message must either contain, or have attached, a Git-formatted patch +against this document which accomplishes the suggested change. The patch should +be based on the master branch of the official +https://projects.archlinux.org/tu-bylaws.git/[tu-bylaws repository] and should +be sent "inline" (i.e. using `git send-email`) so that other TUs can easily +comment on specific parts. The strings `[PATCH]` and `[tu-bylaws]` should be +included in the subject. `git send-email --annotate` can be used to edit a +patch before sending it to the mailing list. + +Sending multiple patches is generally discouraged and should only be done if no +more than one of the patches are subject for debate (the remaining patches +might be formatting changes or minor wording changes). If multiple patches are +sent as part of one proposal, a cover letter describing the changes must be +included. The `--cover-letter` option of `git send-email` can be used to +achieve this. + +SVP is commenced at the time of the motion, with a discussion period of 5 days, +a quorum of 75%, and a voting period of 7 days. SVP( amend_bylaws, 5, 0.75, 7); -- 1.8.4.rc3.500.gc3113b0
[aur-general] [tu-bylaws] [PATCH 0/2] TU bylaws amendment
Ok, sending this before the voting period for Xyne's proposal is over since it is already clear that it will be accepted. More than 65% of all TUs voted "yes" and there are zero "no" votes so far :) The first patch is a follow-up to Xyne's proposal and is something he simply forgot when writing the patch. The second patch adds some information on how to submit patches for TU bylaws amendments. It answers following questions and solves following issues: * Where is the official bylaws Git repository? * Proposals with bad formatting that are hard to comment on. * How to submit formatting changes and actual changes at once without creating messy patches. Let the discussion period begin. Lukas Fleischer (2): Add note on when the number of TUs is recorded Add details on patch submissions tu-bylaws.txt | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) -- 1.8.4.rc3.500.gc3113b0
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On 2013-08-16 11:00 +0200 Lukas Fleischer wrote: >On Thu, Aug 15, 2013 at 03:15:27PM +, Xyne wrote: >> Hi, >> >> The discussion period has ended. Please cast your votes: >> https://aur.archlinux.org/tu/?id=70 > >I know that it is a bit late for comments on the proposal but I just >noticed that your patch doesn't seem to change the sentence mentioning >that TUs are counted at the end of a vote. Is that intentional or did >you just miss that? I did indeed forget to add a statement that TUs should be counted at the beginning of the voting period. I can't find any clause that states the quorum is counted at the end, only participation. I suggest the following additional change, which adds a clause to the SVP section and patches the current Quorum section: > >Only those TUs who are counted towards quorum may participate in the vote. > >[[Q]] >Quorum >-- > >Quorums ensure that all matters decided by vote are representative of the TU >group. All TUs are expected to participate in all votes and the preceding >discussions whenever possible. > >Quorum shall be 66% of all TUs at the start of the voting period 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. > Given that this was part of the discussion I doubt that anyone who voted yes would object to the changes, but I do not know how to proceed. On 2013-08-16 13:10 +0200 Florian Pritz wrote: >On 16.08.2013 11:00, Lukas Fleischer wrote: >> Also, I just wondered whether it is okay to accept a proposal before the >> voting period ends? Currently, there are 19 yes votes, 37 TUs and there >> is no way the number of TUs can increase until the end of the proposal. > >No, people should be allowed to vote no if they feel the change is wrong >just for the sake of letting the others know. (IMHO) > >I'm not sure if we have any rule about that though. In case you can't >find one assume we can't accept it before the end. > We have encountered this situation before. The consensus was that it is better to wait and let everyone cast their vote, even if acceptance is guaranteed. By our own bylaws, the votes are tallied at the end of the voting period anyway. Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On 16.08.2013 11:00, Lukas Fleischer wrote: > Also, I just wondered whether it is okay to accept a proposal before the > voting period ends? Currently, there are 19 yes votes, 37 TUs and there > is no way the number of TUs can increase until the end of the proposal. No, people should be allowed to vote no if they feel the change is wrong just for the sake of letting the others know. (IMHO) I'm not sure if we have any rule about that though. In case you can't find one assume we can't accept it before the end. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
On Thu, Aug 15, 2013 at 03:15:27PM +, Xyne wrote: > Hi, > > The discussion period has ended. Please cast your votes: > https://aur.archlinux.org/tu/?id=70 I know that it is a bit late for comments on the proposal but I just noticed that your patch doesn't seem to change the sentence mentioning that TUs are counted at the end of a vote. Is that intentional or did you just miss that? Also, I just wondered whether it is okay to accept a proposal before the voting period ends? Currently, there are 19 yes votes, 37 TUs and there is no way the number of TUs can increase until the end of the proposal. > > Regards, > Xyne
Re: [aur-general] [tu-bylaws][PATCH] Voting Period
Hi, The discussion period has ended. Please cast your votes: https://aur.archlinux.org/tu/?id=70 Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH]
On Sun, Aug 11, 2013 at 10:29:42AM +, Xyne wrote: > [...] > Patch follows: I put that patch on a separate branch (proposal-70) in the official TU bylaws repository [1], so that it is easier for people to extract the actual commit and review the changes in the way they prefer. I think it is a good idea to include both the discussion and a link to the proposal branch in the AUR proposal description. Xyne, could you please remember this when the voting period starts? I think we should also update the bylaws and complete the "Amendment of Bylaws" section with instructions on how to submit future proposals. Mention the Git repository, mention `git send-email`. Mention that every proposal will be merged into a separate branch so that TUs can easily review the latest version when voting. I will submit a proposal after the end of the voting period for this one. [1] https://projects.archlinux.org/tu-bylaws.git/?h=proposal-70
Re: [aur-general] [tu-bylaws][PATCH]
Lukas Jirkovsky wrote: >I can't obviously comment on grammar as I'm not a native speaker, so I >have just a single comment. I think it may be better to split this >into two commits, one containing the little changes like referring to >trusted users as TUs or explicitly mentioning the aur-general and the >other one containing the recently discussed changes regarding the >voting procedure and TU removal. I have considered that but at this point it would just require more work for no real benefit. I would prefer to leave the proposal as-is. If it is rejected then I or someone else can extract the linguistic changes. Regards, Xyne
Re: [aur-general] [tu-bylaws][PATCH]
On 9 August 2013 13:29, Xyne wrote: > Hi, > > Here's a patch for the TU-bylaws that resulted from discussion in the previous > thread: I can't obviously comment on grammar as I'm not a native speaker, so I have just a single comment. I think it may be better to split this into two commits, one containing the little changes like referring to trusted users as TUs or explicitly mentioning the aur-general and the other one containing the recently discussed changes regarding the voting procedure and TU removal. Lukas
Re: [aur-general] [tu-bylaws][PATCH]
On 11 August 2013 18:29, Xyne wrote: > The current by-laws try to automate a process that requires human discretion. > This version retains automation for extreme cases and relies on human > discretion for the rest. Alright, this justifies those changes. Good to go on the rest, AFAICS. -- GPG/PGP ID: C0711BF1
Re: [aur-general] [tu-bylaws][PATCH]
Rashif Ray Rahman wrote: >On 9 August 2013 19:29, Xyne wrote: >> ... >> * remove distinction between "active" and "inactive" TUs > >So now what happens when so-called active or inactive TUs do not vote >and prevent quorum from being established? No action is taken? I see >these changes cover disappearing TUs, but not non-participating TUs. I >may also just be missing something. >> +OR who has not voted in a consecutive series of voting periods, the starting > >How many "consecutive series"? The full phrase is "who has not voted in a consecutive series of voting periods, the starting dates of which span 2 months or more, shall be brought up for special removal due to inactivity". The sub-clause thus specifies that the length of the series is determined by time, not by number of votes. So, any TU that misses all votes during a period of 2 months falls under the special case for removals. This replaces the old clause specifying 3 votes, as they could easily occur in the same week. Being inactive for a week should not be grounds for special removal. Remember though, this is just for invocation of the special case. If any TU notices that any other TU habitually misses votes then we can start a discussion about it and motion for that TU's removal if deemed appropriate. The other thread contained a suggestion for a TU status page that would show vote participation over some fixed period of time to facilitate the determination of participation. The current by-laws try to automate a process that requires human discretion. This version retains automation for extreme cases and relies on human discretion for the rest. In either case, someone still has to monitor activity of other TUs to determine if there are grounds for removal, but this way will avoid silly edge cases. It is our responsibility to keep an eye on each other, rather than simply induct new TUs and then forget about them until some special case occurs. >> +A motion must be made by at least two TUs for the removal of a >> +TU. The motion must be sent to >-removal of a >+removal of another There is no reason to prevent a TU from motioning for his own removal, even if it would be silly to do so. I have reworded the clause in a more natural way: +A motion for the removal of a TU must be made by at least 2 TUs. The motion must +be sent to Patch follows: From abf7664c2b8c99a2e14b8aff8e37b727fdce7d9b Mon Sep 17 00:00:00 2001 From: Xyne Date: Wed, 7 Aug 2013 13:55:37 + Subject: [PATCH] Following discussion on aur-general (https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html): * remove distinction between "active" and "inactive" TUs * update all clauses affected by this change, most importantly the definition of quorum * update conditions for special removal of a TU * use abbreviations consistently through the document * add missing links to instances of "aur-general" * various changes to correct or improve English throughout the document --- tu-bylaws.txt | 139 ++ 1 file changed, 61 insertions(+), 78 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..4e8c5e2 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -1,7 +1,7 @@ Trusted User Bylaws === Trusted Users -1.2, 18 January 2011 +1.3, 2013-08-07 Summary --- @@ -12,7 +12,7 @@ duties. Mission --- -The Trusted Users serve the following purposes: +The Trusted Users (TUs) serve the following purposes: 1. Maintain +[community]+ as an intermediary between Archlinux's official repositories and the +unsupported+ package collection in the AUR. @@ -22,10 +22,10 @@ repositories and the +unsupported+ package collection in the AUR. Bylaws -- -The bylaws are written to be consistent with the mission of the Trusted Users, -and to ensure that Trusted Users continue to be *Trusted* in the future. They -are also written with the intent to keep the Trusted User organization a -thriving one, fulfilling their purpose. +The bylaws are written to be consistent with the mission of the TUs, +and to ensure that TUs continue to be *Trusted* in the future. They +are also written with the intent to keep the TU organization a +thriving one, fulfilling its purpose. Standard Voting Procedure - @@ -35,31 +35,28 @@ 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 proposal must also be worded -unambiguously, and such that a YES or NO answer may be given. +the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general +mailing list] (aur-general). The proposal must also be worded unambiguously, +such that a YES or NO answer may be given. -The discussion period begins when the proposal is posted on aur-general. The +T
Re: [aur-general] [tu-bylaws][PATCH]
On 9 August 2013 19:29, Xyne wrote: > ... > * remove distinction between "active" and "inactive" TUs So now what happens when so-called active or inactive TUs do not vote and prevent quorum from being established? No action is taken? I see these changes cover disappearing TUs, but not non-participating TUs. I may also just be missing something. > ... > * various changes to correct or improve English throughout the document While you're at it: > ... > mailing list] (aur-general). The proposal must also be worded unambiguously, > and such that a YES or NO answer may be given. -and such that +such that > ... > 2. quorum was established and the number of NO votes is greater than or equal > to the number of YES votes -quorum was established +quorum has been established > ... > +Quorums were established to ensure that all matters decided by vote are > +representative of the TU group. All TUs are expected to participate in all The terms "quorum" and "established" are already used in the document with a different meaning, so different wording could be used here, e.g.: +Quorums ensure that matters decided by vote are +representative of the voters as a group. All TUs are expected to participate in all > +A motion must be made by at least two TUs for the removal of a > +TU. The motion must be sent to -removal of a +removal of another > https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general], and > contain a detailed and valid reason that the TU in question should be > removed. -that the +why the > +OR who has not voted in a consecutive series of voting periods, the starting How many "consecutive series"? > +is followed by a discussion period of three days, a quorum of 66%, and a > voting -three days +3 days -- GPG/PGP ID: C0711BF1
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
[aur-general] [tu-bylaws][PATCH]
Hi, Here's a patch for the TU-bylaws that resulted from discussion in the previous thread: https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html I hope this is in the correct format. I haven't used git send-email because I still haven't configured it and didn't want to risk doing something stupid in a hurry. For those of you who prefer reading the resulting document, I have attached the source file and the generated HTML file. Please read through the previous thread for an explanation of the changes. Let the discussion period begin! From 8328526fc0fef469d9edb1abf0f0448c2f440e90 Mon Sep 17 00:00:00 2001 From: Xyne Date: Wed, 7 Aug 2013 13:55:37 + Subject: [PATCH] Following discussion on aur-general (https://mailman.archlinux.org/pipermail/aur-general/2013-August/024745.html): * remove distinction between "active" and "inactive" TUs * update all clauses affected by this change, most importantly the definition of quorum * update conditions for special removal of a TU * use abbreviations consistently through the document * add missing links to instances of "aur-general" * various changes to correct or improve English throughout the document --- tu-bylaws.txt | 122 -- 1 file changed, 50 insertions(+), 72 deletions(-) diff --git a/tu-bylaws.txt b/tu-bylaws.txt index 991d683..4c0699b 100644 --- a/tu-bylaws.txt +++ b/tu-bylaws.txt @@ -1,7 +1,7 @@ Trusted User Bylaws === Trusted Users -1.2, 18 January 2011 +1.3, 2013-08-07 Summary --- @@ -12,7 +12,7 @@ duties. Mission --- -The Trusted Users serve the following purposes: +The Trusted Users (TUs) serve the following purposes: 1. Maintain +[community]+ as an intermediary between Archlinux's official repositories and the +unsupported+ package collection in the AUR. @@ -22,10 +22,10 @@ repositories and the +unsupported+ package collection in the AUR. Bylaws -- -The bylaws are written to be consistent with the mission of the Trusted Users, -and to ensure that Trusted Users continue to be *Trusted* in the future. They -are also written with the intent to keep the Trusted User organization a -thriving one, fulfilling their purpose. +The bylaws are written to be consistent with the mission of the TUs, +and to ensure that TUs continue to be *Trusted* in the future. They +are also written with the intent to keep the TU organization a +thriving one, fulfilling its purpose. Standard Voting Procedure - @@ -35,31 +35,23 @@ 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 proposal must also be worded +the https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general mailing list] (aur-general). The proposal must also be worded unambiguously, and such that a YES or NO answer may be given. -The discussion period begins when the proposal is posted on aur-general. The +The discussion period begins when the proposal is posted on https://mailman.archlinux.org/mailman/listinfo/aur-general[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 +shall take place on https://mailman.archlinux.org/mailman/listinfo/aur-general[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. +NO or ABSTAIN. Votes shall be cast under the Trusted User section of the https://aur.archlinux.org/[AUR website]. At the end of the voting period, all votes shall be tallied. The proposal is accepted if EITHER -1. the number of YES votes is greater than half the number of active TUs OR +1. the number of YES votes is greater than half the number of TUs OR 2. quorum has been established and the number of YES votes is greater than the number of NO votes @@ -68,8 +60,7 @@ UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER -1. the number of NO votes is greater than or equal
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
[aur-general] [tu-bylaws] [PATCH] Makefile: Declare clean target .PHONY
Signed-off-by: Lukas Fleischer --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e0dcb17..17f28f1 100644 --- a/Makefile +++ b/Makefile @@ -6,4 +6,4 @@ all: tu-bylaws.html clean: rm tu-bylaws.html -.PHONY: all +.PHONY: all clean -- 1.8.0
[aur-general] [tu-bylaws] [PATCH] Add Makefile and ".gitignore"
Signed-off-by: Lukas Fleischer --- .gitignore | 1 + Makefile | 9 + 2 files changed, 10 insertions(+) create mode 100644 .gitignore create mode 100644 Makefile diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..2d19fc7 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +*.html diff --git a/Makefile b/Makefile new file mode 100644 index 000..e0dcb17 --- /dev/null +++ b/Makefile @@ -0,0 +1,9 @@ +all: tu-bylaws.html + +%.html: %.txt + asciidoc -a toc $< + +clean: + rm tu-bylaws.html + +.PHONY: all -- 1.8.0
