[aur-general] TUs and their following of the Bylaws

[Lukas Fleischer]

On Mon, Aug 05, 2013 at 06:32:57AM +0800, Rashif Ray Rahman wrote:
> On 4 August 2013 21:35, Lukas Fleischer <archlinux at cryptocrack.de> wrote:
> > Trying to automate this, I just submitted a couple of AUR patches to
> > aur-dev [1].
> >
> > Based on this, we could:
> >
> > * Add another simple patch that simply displays whether a vote is
> >   accepted or not. This leaves no room for discussion on the results of
> >   future votes.
> >
> > * Implement auto-initiation of removal procedures for repeated quorum
> >   offenses.
> >
> > That do you think about that?
> 
> Excellent, but it looks like there's a problem with when the status
> should be counted. We must allow a TU to become active during a vote
> -- it will simply be wrong to deny her the right to vote simply
> because she was not active at the start.
> 
> An inactivity status must have an accompanying duration, be it a real
> input (start, end date), informative text ("Holidays til sept"), or an
> e-mail (as is presently warranted by the bylaws). Having an input
> complicates the automation, but an e-mail also becomes manual burden.

I don't really like the idea of having to specify an exact end date. If
you are inactive due to, say, a long hospital stay or a lack of an
internet connection after moving you will have to update the end date
continuously. Being inactive usually means that you're offline most of
the time so this might turn out to be a real burden.

Another suggestion: Count every TU that is active during the voting
period (no matter when, no matter how long). That is pretty simple to
implement: Store all active TUs when a vote starts, add a TU to that
list (for all running votes) whenever he becomes active.

> 
> The case of an MIA is different. There may not be three consecutive
> votes during the period of absence, so automatic removal won't happen.
> The removal must be proposed based on other activity criteria, such as
> (lack of) packaging. So this cannot be automated.
> 
> All of these are not set in stone -- the bylaws can be modified to
> better fit an automated system. To begin with, it must be modified if
> the proposed changes are committed verbatim (defining activity status,
> removal procedure), subject to a vote.
> 
> 
> --
> GPG/PGP ID: C0711BF1