[aur-general] [tu-bylaws] [PATCH] Honor TUs who become active/inactive during votes

[Lukas Fleischer]

On Wed, Aug 07, 2013 at 06:50:36PM +0000, Xyne wrote:
> [...]
> The distinction between "active" and "inactive" TUs is meaningless and should
> be removed from the bylaws, including the definition of quorum. Quorum will
> therefore be some fixed percent of all TUs. As stated in this thread, up to 1
> in 3 can skip the vote, and omitting "inactive" TUs defeats the purpose of
> quorum. There will therefore be no need for an "active" flag on TU user
> accounts on the AUR.

+1.

> 
> I still like my own suggestion for amending the removal section to add the
> special case for TUs who have not touched [community], AUR or the mailing list
> in 2 months. I believe that accomplishes the real goals of the current clauses
> regarding unannounced inactivity and quorum blocking. All other cases in which
> a TU is perceived to be avoiding his or her duties can be handled by the
> standard removal procedure.

+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.

> 
> 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. 

Ok, agreed.

> 
> 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.

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?

> 
> 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.

> 
> 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? :)

> 
> 
> Regards,
> Xyne

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?

> 
> p.s.  you can stop CC'ing me now ;)
>