[aur-general] On TU application, TU participation and community/ package quality

[Santiago Torres-Arias]

On TU applications, TU participation and package quality:
=========

Many Trusted Users have brought up their concerns regarding the lack
of proper vetting of packages put forward by new TU's, the small
participation of TUs in their duties* and the declining quality of
packages in the community/ repository. As a consequence, we've decided
to bring forward proposals to tackle the following issues:

## Issues

* Existing Trusted Users are not followed closely in their actions, and
  the quality of some packages for instance is more than questionable.
* New applications are not carefully reviewed, and a several TUs seem to
  just vote “Yes” by default.
* There is a general feeling of decreasing/not high enough quality in
  the packages provided in the community/ repository.
* The implication of some TUs in the distribution is very limited
  outside of packaging.

### current proposals (simplified)

The discussion #archlinux-tu channel has yielded three general
possibilities:

1. Add a council of TU's to introduce oversight on the whole voting
   process
2. Increase the minimum number of sponsors per application
3. Create a working group of TU's to review recent applications and
   warn TU's that do *not* appear to be performing their duties
   appropriately

Consider that these need not be the only possibilities and any further
proposals should be also brought up.

## Proposals

### TU council

Creating a council of TUs who, by means of experience and involvement,
make sure the approval of new TU's is properly reviewed. As such, this
council will be in charge of voting in and/or sponsoring a new TU
applicant.

This raises questions about the horizontal power structure of the TU
community. The consequences of bringing a hierarchy like this need to be
discussed, as more than one TU is concerned of the implications of this
model.

The means for election for such a council are yet to be discussed, as
the feasibility of this measure is to be discussed first.

### Minimum number of sponsors

An alternative to a TU council is to increase the minimum number of
sponsors for a TU application. This has been the case in other
communities that experienced rapid growth (e.g., CNCF) and may help
increase oversight and preparation of newer applicants.

Variants of this model can be considered too. For example, a buddy
system in which new applicants need both an experienced TU and a new TU
as sponsors may also help preparing new TU's with the process of
preparing applicants.

However, one question raised during the discussion is whether this model
is enough to warrant the goals outlined above. Namely, this measure
doesn't seem to tackle the lack of participation of the broader TU
community when reviewing new TU applications. 

### Oversight committee

Finally, a third proposal (and the one I'm championing) is to generate
an elected organism within the TU community to overlook the performance
of Trusted Users on the duties they agreed to fulfill. This oversight
committee would track the activities of individual TUs and ensure that
they are in fact participating in reviews, submitting proper
high-quality PKGBUILDS, and moving packages to and from the AUR when the
package's popularity changes.

The methods by which this committee would enforce better TU
participation are still to be discussed, but issuing warnings and
probably bring cases to the broader TU community regarding an
underperforming TU may be sufficient and nondisruptive.

## Conclusions

The proposals above serve as a first step to discuss and iteratve over
ideas on how to improve TU participation, applications and package
quality. With this in mind, discussion of the applicability of these (or
any other proposal) alone or on tandem should follow suit.

Thanks!
-Santiago

P.S.: sorry for the legalose tone. I've probably spent too much time
this week going through governance documents for different communitites.

P.S.: Some of the ideas put forward is my interpretation of the text
after going through the irc logs. Please correct me if my interpretation
is wrong or incomplete.

* e.g., reviewing PKGBUILDs or going through AUR requests
-------------- 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/20181111/7b7d6d1a/attachment.asc>