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
pgpo7C3lT4tbi.pgp
Description: PGP signature
