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

[Eli Schwartz]

On 1/8/19 11:30 AM, Andrew Crerar wrote:
> On 1/8/19 4:31 PM, Santiago Torres-Arias via aur-general wrote:
>> On Tue, Jan 08, 2019 at 07:55:47AM -0200, Giancarlo Razzolini wrote:
>>> Em janeiro 8, 2019 0:23 Santiago Torres via aur-general escreveu:
>>>> - Have two TUs review the applicants PKBUILDs
>>>> - Have two TUs actually decide to support this canididate
>>>
>>> I'm fine with the patch, but these two lines are ambiguous. Are the TUs that are
>>> going to review the PKGBUILD's the same as the sponsors? 
>>
>> This is a good point. My understanding is that sponsors generally do a
>> preliminary review, yet everyone is encouraged to continue reviewing any
>> PKGBUILDS during the discussion period.
>>
>>> Also, if we are heading
>>> this direction of having a different set, other than the sponsors, of TUs requiring
>>> to review the PKGBUILD's, shouldn't this also be added to the bylaws?
>>
>> This is also true. I'm not sure if that's something we want to put in
>> the bylaws or it's just somewhat of an untold rule/expectation.
>>
>> What're everyone's thoughts on this?
>>
>> Thanks,
>> -Santiago.
>>
> 
> I don't think the bylaws should *explicitly* state or require two additional,
> non-sponsoring TU's to conduct reviews. I can think of a number of downsides
> with making that a requirement with possibly one upside.
> 
> However, I do think it should be a well-known and documented (i.e. in the wiki)
> best-practice that during the review process, there's two or more non-sponsoring
> TU's reviewing the applicant's packages. Informal, but effective.

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

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.

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

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.

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.

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

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

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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190108/8173b7ca/attachment.asc>