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

[Christian Rebischke]

On Sun, Nov 11, 2018 at 01:29:31PM -0500, Discussion about the Arch User Repository (AUR) wrote:
> 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

Hello Santiago,

First of all thanks for rewriting this up:
https://lists.archlinux.org/pipermail/arch-dev-public/2018-November/029392.html

I have a few questions about your oversight comittee. You wrote:
> 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.


When I understand this correctly you want to punish TUs when they don't
fullfill their duties. How do you want to accomplish this and what do
you mean with 'moving packages to and from the AUR whrn the package's
popularity changes'? So only this commitee should be able to push new
packages to [community]?

Best regards,

Chris
-------------- 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/b2c2599c/attachment.asc>