[aur-general] discussion about activity
Hi, I want to discuss our notions of "activity". According to the current bylaws,
If a TU becomes inactive without declaring it, "disappears", someone must motion for their removal for reason of unwarranted and undeclared inactivity, and the normal procedure for the motion is followed.
The problem is that there is no definition of "active" here. The text may be interpreted to mean that a motion should be made if a TU has any AUR packages flagged out-of-date, which is presumably not the intention. The only metric we currently have for determining inactivity is
active TUs that keep quorum from being established on a voting procedure for three consecutive voting procedures (they need not be on the same motion) are automatically brought up for removal procedure, by reason of unwarranted inactivity.
That is also a useless metric, as 3 votes could easily be called simultaneously the same day that a TU was hit by a car. As I see it, these clauses are trying to achieve two different things: 1) provide a way to remove TUs who clearly have no intention of fulfilling their duties 2) ensure that vote results are representative of the group I think there is a better way to achieve that which avoids the ambiguities and other problems of the current text. I propose, **as a starting point for the discussion**, that we remove the aforementioned clauses (and dependent context). To deal with removing inactive users, the following can be added to the end of the "Removal of a TU" section, replacing the current clause of special removals:
An exception to the standard removal procedure is made if a TU 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 aur-general
In this special case, SVP is followed by a discussion period of three days, a quorum of 66%, and a voting period of 5 days.
The first point is verifiable for all cases except AUR package removal. The second point is verifiable in the case of votes but not for moderation actions such as merges and deletions of other packages. This could possibly be changed in the AUR backend. The third is obviously verifiable. This clause does not preclude the removal of TUs for other reasons and the bylaws currently allow for removal motions at any time. If a TU only posts inconsequential messages to the mailing list once every two months to avoid activating the clause then he or she can still be brought up for removal. The clause is essentially a "housekeeping clause for automatic cleanup of completely inactive TUs. With Lukas' new patch set, the AUR will now have an activity field. I also propose that the meaning of this field be limited strictly to quorum, and thus be completely independent of the definition of activity above. A TU should mark him-/herself as inactive only when he/she will be unable to participate in votes for a period of time. The TU will then be excluded from the quorum calculation (and also prevented from voting, and possibly other activities). Again, there is no need to include a clause in the bylaws for automatic motions if a TU prevents quorum from being reached. The motion can be raised without such a clause. This is natural. If three votes on the same day fail to meet quorum then it is clearly a different case then three votes over the course of 1-2 months. The field should perhaps be made a checkbox named "present" rather than "active". With these changes, other parts of the section of the bylaws entitles "Active vs. Inactive" will need to be changed, as declaring inactivity to aur-general will have no significance.* This avoids problems with truly unforeseeable absences such as connection problems and medical emergencies. Users may still make optional announcements at their own discretion with the usual requests for others to manage their packages for a period of time, if necessary. I have attached a first draft (new.txt) of these proposals along with a patch. Note that this is not a formal proposal. I plan to make one but I hope to get some feedback first. Please read through the attached version and compare it to the current version. The attachments also include the old version, the patch, a brief changelog, and the resulting HTML document for easier reading and comparison to https://aur.archlinux.org/trusted-user/TUbylaws.html The bylaws Git repo can be found here: https://projects.archlinux.org/tu-bylaws.git/ Note that I have made some stylistic changes that preserve the original meaning. I can separate these from the proposal if necessary. Regards, Xyne * Incidentally, I have always been uncomfortable with the way inactivity announcements are expected to be made on a public mailing list. Inactivity is almost always due to being away from home for a period of a week or more. Announcing that in public is an open invitation to burglars and other griefers who know who the announcer is and where he/she lives.
On Wed, Aug 07, 2013 at 02:10:45PM +0000, Xyne wrote:
Hi,
I want to discuss our notions of "activity". According to the current bylaws, [...]
This discussion starts to get messy. Now there are three different threads discussing the same thing, basically. Could we please concentrate on the current proposal and the related discussion before initiating a new one? Also, you still didn't comment on the suggestion to remove the activity part from the quorum computation altogether. Please read Sébastien's reply (and follow-ups) to my proposal. The quorum is meant to ensure that a result is representative. If 60% of all TUs are inactive, we can currently establish a quorum of 100%. This does not seem right to me. Also, dropping the activity restriction makes things a lot easier, so this gets a +2 from me...
On Wed, Aug 7, 2013 at 12:13 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Wed, Aug 07, 2013 at 02:10:45PM +0000, Xyne wrote:
Hi,
I want to discuss our notions of "activity". According to the current bylaws, [...]
This discussion starts to get messy. Now there are three different threads discussing the same thing, basically. Could we please concentrate on the current proposal and the related discussion before initiating a new one?
Also, you still didn't comment on the suggestion to remove the activity part from the quorum computation altogether. Please read Sébastien's reply (and follow-ups) to my proposal. The quorum is meant to ensure that a result is representative. If 60% of all TUs are inactive, we can currently establish a quorum of 100%. This does not seem right to me. Also, dropping the activity restriction makes things a lot easier, so this gets a +2 from me...
A simple majority of 51% isn't a consensus among the team, regardless of how many people voted. I don't think proposals should pass at all when nearly half of us object. Rather than the quorum, we could require a super-majority (60%, 70%) of the trusted users to vote YES and handle inactivity removals separately. If 8 people are on vacation, it's not a good time to be passing proposals.
On 2013-08-07 11:26, Daniel Micay wrote:
On Wed, Aug 7, 2013 at 12:13 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Wed, Aug 07, 2013 at 02:10:45PM +0000, Xyne wrote:
Hi,
I want to discuss our notions of "activity". According to the current bylaws, [...]
This discussion starts to get messy. Now there are three different threads discussing the same thing, basically. Could we please concentrate on the current proposal and the related discussion before initiating a new one?
Also, you still didn't comment on the suggestion to remove the activity part from the quorum computation altogether. Please read Sébastien's reply (and follow-ups) to my proposal. The quorum is meant to ensure that a result is representative. If 60% of all TUs are inactive, we can currently establish a quorum of 100%. This does not seem right to me. Also, dropping the activity restriction makes things a lot easier, so this gets a +2 from me...
A simple majority of 51% isn't a consensus among the team, regardless of how many people voted. I don't think proposals should pass at all when nearly half of us object.
Rather than the quorum, we could require a super-majority (60%, 70%) of the trusted users to vote YES and handle inactivity removals separately.
If 8 people are on vacation, it's not a good time to be passing proposals. I'm (obviously) not a TU, so I know my thoughts probably don't count for much, but there is one thing I'd like to point out. Abstentions and non-votes are not the same as "no votes". Perhaps, instead of a super majority, requiring no less than a certain number of no votes would be a good idea. For instance, allowing 50%+1 to pass so long as there are no more than 33% would be a fairly functional model. The other possibility, of course, would be to define all non-votes and abstentions as "no" votes (save non-votes/abstentions by inactive TUs). This is a much stricter system but I don't believe accurately represents vote casts.
Again, my word probably doesn't mean that much, but I have some strong opinions about how voting should be done (student of political science), so I figured it might be worth throwing something out there. All the best, -Sam
On 2013-08-07 11:33, Sam Stuewe wrote:
and non-votes are not the same as "no votes". Perhaps, instead of a super majority, requiring no less than a certain number of no votes would be a good idea. For instance, allowing 50%+1 to pass so long as there are no more than 33% would be a fairly functional model. To clarify, that would be "so long as there are no more than 33% voting against." This creates an artificial super-majority which still only requiring a simple majority to pass. All the best,
-Sam
On Wed, Aug 7, 2013 at 12:35 PM, Sam Stuewe <halosghost@archlinux.info> wrote:
On 2013-08-07 11:33, Sam Stuewe wrote:
and non-votes are not the same as "no votes". Perhaps, instead of a super majority, requiring no less than a certain number of no votes would be a good idea. For instance, allowing 50%+1 to pass so long as there are no more than 33% would be a fairly functional model.
To clarify, that would be "so long as there are no more than 33% voting against." This creates an artificial super-majority which still only requiring a simple majority to pass.
All the best,
-Sam
That's a good point, I agree.
On 2013-08-07 14:10, Xyne wrote:
Hi,
I want to discuss our notions of "activity". According to the current bylaws,
If a TU becomes inactive without declaring it, "disappears", someone must motion for their removal for reason of unwarranted and undeclared inactivity, and the normal procedure for the motion is followed.
The problem is that there is no definition of "active" here. The text may be interpreted to mean that a motion should be made if a TU has any AUR packages flagged out-of-date, which is presumably not the intention.
The only metric we currently have for determining inactivity is
active TUs that keep quorum from being established on a voting procedure for three consecutive voting procedures (they need not be on the same motion) are automatically brought up for removal procedure, by reason of unwarranted inactivity.
That is also a useless metric, as 3 votes could easily be called simultaneously the same day that a TU was hit by a car.
As I see it, these clauses are trying to achieve two different things: 1) provide a way to remove TUs who clearly have no intention of fulfilling their duties 2) ensure that vote results are representative of the group
I think there is a better way to achieve that which avoids the ambiguities and other problems of the current text.
I propose, **as a starting point for the discussion**, that we remove the aforementioned clauses (and dependent context). To deal with removing inactive users, the following can be added to the end of the "Removal of a TU" section, replacing the current clause of special removals:
An exception to the standard removal procedure is made if a TU 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 aur-general
In this special case, SVP is followed by a discussion period of three days, a quorum of 66%, and a voting period of 5 days.
66% of the total, or of those that voted? I also think a minimum amount of votes should be mentioned here (much like for TU applications).
The first point is verifiable for all cases except AUR package removal. The second point is verifiable in the case of votes but not for moderation actions such as merges and deletions of other packages. This could possibly be changed in the AUR backend. The third is obviously verifiable.
Shouldn't TUs send an email to aur-general when a package is deleted? I though that was the case, and that's why we include package names in links; so that archival of this sort of data is kept in the list; for posterity's sake. That would mean the removal of packages is covered by (3).
This clause does not preclude the removal of TUs for other reasons and the bylaws currently allow for removal motions at any time. If a TU only posts inconsequential messages to the mailing list once every two months to avoid activating the clause then he or she can still be brought up for removal.
The clause is essentially a "housekeeping clause for automatic cleanup of completely inactive TUs.
With Lukas' new patch set, the AUR will now have an activity field. I also propose that the meaning of this field be limited strictly to quorum, and thus be completely independent of the definition of activity above. A TU should mark him-/herself as inactive only when he/she will be unable to participate in votes for a period of time. The TU will then be excluded from the quorum calculation (and also prevented from voting, and possibly other activities).
Again, there is no need to include a clause in the bylaws for automatic motions if a TU prevents quorum from being reached. The motion can be raised without such a clause. This is natural. If three votes on the same day fail to meet quorum then it is clearly a different case then three votes over the course of 1-2 months.
The field should perhaps be made a checkbox named "present" rather than "active".
With these changes, other parts of the section of the bylaws entitles "Active vs. Inactive" will need to be changed, as declaring inactivity to aur-general will have no significance.* This avoids problems with truly unforeseeable absences such as connection problems and medical emergencies. Users may still make optional announcements at their own discretion with the usual requests for others to manage their packages for a period of time, if necessary.
I have attached a first draft (new.txt) of these proposals along with a patch. Note that this is not a formal proposal. I plan to make one but I hope to get some feedback first. Please read through the attached version and compare it to the current version. The attachments also include the old version, the patch, a brief changelog, and the resulting HTML document for easier reading and comparison to https://aur.archlinux.org/trusted-user/TUbylaws.html
The bylaws Git repo can be found here: https://projects.archlinux.org/tu-bylaws.git/
Note that I have made some stylistic changes that preserve the original meaning. I can separate these from the proposal if necessary.
Regards, Xyne
* Incidentally, I have always been uncomfortable with the way inactivity announcements are expected to be made on a public mailing list. Inactivity is almost always due to being away from home for a period of a week or more. Announcing that in public is an open invitation to burglars and other griefers who know who the announcer is and where he/she lives.
<snip> -- Hugo Osvaldo Barrera
On Sun, Aug 11, 2013 at 07:02:51PM -0300, Hugo Osvaldo Barrera wrote:
[...]
An exception to the standard removal procedure is made if a TU 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 aur-general
In this special case, SVP is followed by a discussion period of three days, a quorum of 66%, and a voting period of 5 days.
66% of the total, or of those that voted? I also think a minimum amount of votes should be mentioned here (much like for TU applications).
The quorum *is* the minimum amount of votes required.
The first point is verifiable for all cases except AUR package removal. The second point is verifiable in the case of votes but not for moderation actions such as merges and deletions of other packages. This could possibly be changed in the AUR backend. The third is obviously verifiable.
Shouldn't TUs send an email to aur-general when a package is deleted? I though that was the case, and that's why we include package names in links; so that archival of this sort of data is kept in the list; for posterity's sake. That would mean the removal of packages is covered by (3).
Nope, they don't have to. If a TU moves a package to [community] or discovers a completely broken package, he usually just removes it without notifying aur-general.
[...]
participants (5)
-
Daniel Micay
-
Hugo Osvaldo Barrera
-
Lukas Fleischer
-
Sam Stuewe
-
Xyne