[aur-general] discussion about activity

Hugo Osvaldo Barrera hugo at osvaldobarrera.com.ar
Sun Aug 11 18:02:51 EDT 2013

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.


Hugo Osvaldo Barrera
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20130811/b6fc0a7c/attachment-0001.asc>

More information about the aur-general mailing list