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

[Xyne]

On 2018-11-12 12:22 +0100
Levente Polyak via aur-general wrote:

>Sure, if we can call out sponsors for lack of proper guidance and
>commitment. Sometimes I have the feeling some sponsors don't do anything
>besides putting their name into an applications and creating a ticket on
>success.
>I know of some sponsors that just didn't take the time to review any
>packages (they personally admitted so) and therefor IMO didn't really
>mentor the applicant. We should take sponsoring more seriously.
>
>I feel a bit sad and like people offload the burden fully on others like
>me when I notice very obvious things as VCS packages that for example
>lack any provides/conflicts (or similar) which is already very well
>documented in our packaging related wiki pages.
>
>Not saying nobody does, but sponsoring should quite frankly be far more
>then just to agree and like that an applicant wants to become a TU.
>Redirecting to another possible sponsor doesn't mean you reject an
>applicant either and that's easy to make clear! To volunteer being a
>sponsor should mean to _potentially_ spend lots of time and patience in
>order to be a mentor that an applicant deserves.

To sponsor a candidate is to declare that you are not only confident in their
packaging and related technical skills but also that you trust them with access
to the community repo and the AUR (whence "trusted" user). To build trust
requires time and observation. TUs should only sponsor candidates that they
have observed regularly over a period of at least several months, preferably
more. You should have a good idea of the candidate's online activity and a
strong positive impression of both the quality of their packages *and* their
temperament. The reason for sponsoring a candidate should never be "meh, why
not?".

Maybe we should stipulate that sponsorship messages consist of more than just
"yep, I've agreed to sponsor X". The sponsor should explain why they've agreed
to sponsor the candidate, how the sponsorship was agreed, how long the sponsor
has been aware of the user in the community, etc. The sponsor should advocate
for the candidate's application. The sponsor should absolutely review the
candidate's packages before the candidate applies here. If a TU sponsors a
candidate with egregiously bad packages (or unacceptable online behavior),
their own suitability should be brought up for discussion.

With the aforementioned approach, I like the idea of multiple sponsors to
ensure a certain level of trust. With the current voting system, if just 1 TU
votes "yes" and enough vote "abstain" to reach quorum, the vote passes. For me,
"abstain" means "I don't know enough about this candidate to support the
application, but I don't see any reason not to either". There should be some
sort of minimum support above 1.
 
However, rather than requiring multiple sponsors just to apply, I suggest
requiring multiple sponsors to proceed to the vote. The procedure would be:
1. A TU identifies a good candidate and discusses the idea with them.
2. The TU reviews the candidate's packages and community participation
   thoroughly and suggests improvements if necessary.
3. Once all suggested improvements have been made, the TU agrees to sponsor and
   the candidate applies.
4. The TU confirms and explains their sponsorship, citing specifics.
5. Other TUs review the application. TUs that are confident in the candidate
   after review then vouch for the candidate by co-sponsoring them. In addition
   to the quality of packages, the co-sponsors should have at least been aware
   of the candidate within the community for an extended period of time.
6. If x TUs agree to sponsor within the discussion period, the vote goes ahead 
   as usual. If not, the candidate has to wait as usual to reapply. During the
   wait, TUs can pay closer attention to the candidate until they feel
   confident enough to co-sponsor.

This is just an idea for discussion. I don't know what a good value for x would
be (how much "trust" is enough?). Sponsoring bad candidates should have
consequences, but I don't see any way to objectively measure or implement that
so it would be a bad idea.

I am entirely opposed to creating a TU council, oversight committee, working
group or any other power hierarchy. All of the mentioned issues can be
addressed without it. If a TU is producing sub-standard packages, just contact
them directly and discuss the issue. If the TU refuses to correct the issue,
start a discussion on the list. If it's actually a problem, it will go to a
vote. In the worst case scenario of widespread TU corruption that prevents a
successful vote, the devs can step in and kick people out, but it should never
come to that (and if it does, it means we all goofed the application process).

Moving packages to community has always been at the TU's discretion irrespective
of votes, so that is not an issue. If you really want to move a package to
community, just contact the current TU maintainer and tell them. Either the
current maintainer will move it, give a reason for not moving it, or let you
move it. Problem solved.

As for other duties, we have a procedure for removing inactive TUs, so there
is no need for special oversight powers, and limited activity is not an issue.
Some hands are more active than others, but all of them are helping with no
extra cost. There are several things that a TU can do to benefit the community
(deal with requests, maintain community and/or AUR packages, police the AUR),
but a TU doesn't have to do all of them.

The only reason that I can see for creating a special class of TU with
authority over the others is to sidestep our current voting procedures. It will
create drama and tension at the expense of a fair process. However well
intentioned it may be, such moves never end well. Please don't do this.

If you (singular or plural) want to review other TUs and bring them up for
discussion, there is nothing stopping you. You don't need special authority,
just a compelling argument. If you don't have the latter, then you definitely
shouldn't have the former.

Just my 0.02 ¤

Regards,
Xyne