[aur-general] [PATCH][tu-bylaws]: raise threshold of sponsors to two

[Santiago Torres-Arias]

On Tue, Jan 08, 2019 at 12:33:46PM -0500, Eli Schwartz via aur-general wrote:
> On 1/8/19 11:30 AM, Andrew Crerar wrote:
> > SNIP't
> I'll go one step further: these guidelines are a good way to ensure
> there will be no new applicants, at all. We should just be honest and
> declare in plain words that we are placing a full, unconditional
> moratorium on applications...

Sigh, I understand where you're coming from.

> 
> Historically, reviews happen by a maximum of one person, and it's almost
> always either me or Levente. And I'm no longer interested in the
> pressure. Now we're getting recent cases where no one reviews at all, or
> someone does but only on the last day of the discussion period.

Sigh, I sadly agree with this. I can only say I'm very thankful for all
the hard work you and levente have put on reivewing peoples PKGBUILDs>

> 
> Wiki documentation does nothing; everyone expects someone else to do it,
> and it's a niche skill in the first place.

Probably, yes. To be quite fair I don't think people would look at the
wiki to see these "soft" duties and keep them as something worth doing.

> 
> Rules without a process to ensure they actually achieve a useful result
> don't do the thing they are intended to do. I guess if people are
> dissatisfied with the application process, then a moratorium might be
> considered a valid alternative, but I think most will agree it is not a
> *good* alternative.

This reads as somewhat threatening. Although I don't completely disagree
with it how it looks. this is what I feels is in the line: the
credibility of TU's as a whole :)

> Bottom line is that perceptions of inefficiencies in the application
> process can only be solved by changing the people doing the voting. It's
> logically inconsistent to blame the rules rather than the voters when
> considering the outcome of the voting counts.

This is a valid point, hence my other suggestions of having a more
institutionalized enforcing mechanism. Yet we care about the "visuals"
of it being horizontal or not. I don't think any proposals in the table
are exclusive though...

> Raising the minimum criteria for considering a valid applicant by
> increasing the number of sponsors is something I can point to and say
> "this is supposed to make sure one person cannot push through a
> candidate on the strength of other people abstaining due to lack of
> knowledge".

This is something that has been proven to increase due dilligence in
other organizations (e.g., the CNCF did just the same last year). I
don't think it happens like magic, but having two careless sponsors is
just probabilistically harder to find :)

> 
> Quite frankly, I agree with what Xyne said here:
> https://lists.archlinux.org/pipermail/aur-general/2018-November/034652.html

I honestly find this protocol a little more verbose and with not much to
change. Again, from the CNCF application process, sponsors generally
know other TU's so they may reach to each other and ask applicants to
propose their co-sponsorship. 

Am I missing something on this point?

> The original sponsors should have done this and more in the first place.
> I don't want to vote for a candidate simply because I cannot find any
> compelling objections -- I want to vote for a candidate because s/he and
> sponsor(s) gave me a passionate reason to believe in them.
>
> My intention for PKGBUILD reviews was always to give another data point
> about the applicant. Not to make that be the only thing anyone cares
> about. I'm severely opposed to any proposal that we codify PKGBUILD
> reviews in the bylaws, as I think it will have the very opposite effect
> and result in a reduction in quality.
> 
I completely agree with these two points. PKGBUILD reviews by fellow
TU's shouldn't be a given, but rather something that may come as a plus.
Again, I cannot stress enough how thankful I am with you and Levente for
your hard work.

-Santiago.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190108/136b3152/attachment.asc>