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: Start End yyyy-mm-dd - yyyy-mm-dd yyyy-mm-dd - yyyy-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 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. >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 himself. > >Am I right? Did I miss anything? 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.
Trusted User Bylaws =================== Trusted Users <aur-general@archlinux.org> 1.3, 2013-08-07 Summary ------- This document describes the bylaws of the Trusted User group, its mission, and duties. Mission ------- 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. 2. Maintain, manage, and watch over the operation of the AUR. Bylaws ------ 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 ------------------------- Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the 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 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 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 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 TUs OR 2. quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER 1. the number of NO votes is greater than or equal to half the number of TUs OR 2. quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected. [[Q]] Quorum ------ 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 votes and the preceding 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. Addition of a TU ---------------- The addition of a TU may occur at any time. 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. ---- SVP( addition_of_TU, 5, 0.66, 7 ); ---- If a candidate is rejected by SVP, they may not reapply to become a Trusted User for a period of three months. Removal of a TU --------------- The removal of a TU may also occur at any time. A motion must be made by at least two TUs for the removal of a TU. The motion must be sent to 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. Following the motion, standard voting procedure commences with a discussion period of 7 days, a quorum of 75% of all TUs except for the TU being considered for removal, and a voting period of 7 days. ---- SVP( general_removal_of_TU, 7, 0.75, 7); ---- The TU brought up for removal may defend themselves during the discussion period, but may not vote on the proposal. Special Removal of an Inactive TU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 3. posted a message to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] OR 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. In this special case, the motion may be made by one TU instead of two, and SVP is followed by a discussion period of three days, a quorum of 66%, and a voting period of 5 days. ---- SVP( removal_of_inactive_TU, 3, 0.66, 5 ); ---- Amendment of Bylaws ------------------- 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. ---- SVP( amend_bylaws, 5, 0.75, 7); ---- If the amendment fails, the same amendment may not be motioned for a period of three weeks.
