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

[Lukas Fleischer]

On Thu, Aug 08, 2013 at 02:16:56PM +0000, Xyne wrote:
> Lukas Fleischer wrote:
> >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.
> 
> By "added to the proposal", do you mean accepted as a TU?

"added to the proposal" as in adding a user to the "Applicant/TU" field
on the "Add Proposal" page.

> 
> 
> >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?
> 
> If a TU resignes after the vote starts then the TU is still counted towards
> quorum, and quorum may fail if the TU doesn't vote. We can always encourage TUs
> to vote before they resign, but in general I do not think that the future of
> any organization should be determined by outgoing members on their way out the
> door. This is not an important issue for me. I also agree that it is better not
> to associate votes with TUs, but I do not expect that to be an issue if it is
> only for the duration of the vote. An AUR admin who wants to peek would modify
> the code if he really wanted.

Ok, agreed.

> >What does this mean in practice? :)
> 
> Let's say that the discussion period for a TU application begins and the vote
> is scheduled to start on Monday. A motion is made for the removal of a TU
> during this period and the vote should normally start on Tuesday. I think the
> application vote should be suspended until the removal vote is finished. It
> affects quorum and the outcome of the vote.
> 
> If two removal votes are scheduled then they occur in the usual order.

Sounds good. I think that this is something that doesn't need to be
implemented in the AUR, though. Just a guideline for people adding
proposals.

> [...]
> I think that's it. I have attached up updated version of my previous
> submission. Take a look and let me know what you think.

+1 from me. I think you should start a new proposal. Please send this as
an inline patch, adding "[tu-bylaws]" to the subject line -- like I did.
People usually do not want to re-read the whole bylaws and exporting the
attached file just to create a diff is unnecessary work. Also, sending
an inline patch allows people for replying and adding comments to
specific sections of the patch.

Sending the proposal as an inline patch can be easily done using

    $ git send-email --annotate HEAD^

after committing the changes and adding a short commit message that
summarize the changes.

Thanks!

> 
> [...]