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

[Robin Broda]

On 11/18/18 3:52 AM, Xyne wrote:
> 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
> 

Should we get these points formalized in the bylaws?

Do you guys think these different improvements should be brought up in separate amendment votes, or all packed in one?
Plenty TUs appear to agree with most things said here, both on the ml and in our top-secret irc channel - however, some have raised issues with part of the suggestions which makes me wonder how we should approach this to reach consensus.

I feel like maybe if we split up each point and have a vote for each of them, we could figure out what exactly the others from the team are looking for - without blocking some of the proposals here by batching them up with the ones that weren't so well received.

What are your thoughts?

-- 
Rob (coderobe)

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181128/9f8e3d05/attachment-0001.asc>