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

Mon Nov 12 11:22:09 UTC 2018

On 11/12/18 12:54 AM, Baptiste Jonglez wrote:
> On 11-11-18, Santiago Torres-Arias via aur-general 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:

Thanks sangy that I could offload to you kick-starting this discussion :)

Nothing here is finger pointing even if you may find yourself matching
an example in any way. We are facing different symptoms and that's the
root why many TUs brought up concerns.
It's not easy to find hard facts for all this, even I can't deliver
those in all my following examples but denying there is something we can
or should improve just ignores why we have this discussion today.

> 
> Before diving in on the proposed solutions, let's make sure we all agree
> on whether there is a problem and what is the problem exactly:
> 
>> ## Issues
>>
>> * Existing Trusted Users are not followed closely in their actions
> 
> Well, that's why it's called *Trusted* Users, right?  Most of the issues
> you mention are actually issues about trust.
> 
> I've made some packaging mistakes in the past, and there was always
> somebody to yell at me.  I wasn't happy at the time and maybe I didn't
> react appropriately, but most of the time the "yeller" was right, and I
> learned from these mistakes so as not to repeat them.
> 
> If we want to increase the level of trust in terms of packaging quality, I
> like the suggestion of a "probation" period in which new TUs have all
> their changes reviewed by their sponsor and/or another TU.
> 
> This seems much more productive and reasonable than a "council of trusted
> Trusted Users" that either acts as a gatekeeper or assesses the
> "performance" of their fellow TUs, whatever that means...

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.

> of 
>> * New applications are not carefully reviewed, and a several TUs seem to
>>   just vote “Yes” by default.
> 
> Do you have any data backing up this claim about voting "Yes" by default?
> Do you mean that some TUs vote "Yes" without reading the TU application thread?

Hard to have data on this, but I can share that I have two samples of
people admitting they haven't really read it, whatever that means, no
idea what the resulting vote was either. No need for a witch hunt here
as well, I have made clear how bad that is (but you asked for examples).

/* Another related example follows two sections below */

> 
> I find this unlikely, we even rejected some TU applications in the past
> (one in 2014, one in 2016 and another in 2017).
> 
> The most likely explanation for the successful applications is that they
> just didn't raise any serious issue worth a rejection.
> 

Don't want to use a too strong language here as we are speaking about
people behind these but i would have lost lots of trust if we didn't.

Anyway, this purely depends on the set of applicants. We should just
fully keep this part out of the equation as it doesn't provide _any_
value or indication if that's too little or too much and there are no
hard fact to back either.

>> * The implication of some TUs in the distribution is very limited
>>   outside of packaging.
> 
> You can't expect everybody to dedicate all their time to Arch: we all live
> different lives and are already involved in various projects.  Let's just
> accept that there are several ways of contributing and that's fine.
> 

Another example I know of: we also have at least one TU who literally
never ever participates in any IRC, mailinglist or Forum discussions and
also didn't vote in the past until we put up that rule about voting.
Magically this lead to voting, but excuse me I lack the trust to believe
this is done in a meaningful way.

So here we are for my final words and conclusion:

I'm fine if people only want to do certain things out of all duties and
not be responsible for proper discussions, reviews or other duties, but
currently that doesn't _really_ work like that.

Putting up even more and stricter rules won't magically solve the
underlying issue and symptoms either.

The word "council" may just be bad choice here as people obviously fear
the goal is to establish power to a few. This is to the same degree
about power as having forum mods, bug wranglers, wiki admins, master key
holders and devops is about having power: Not at all.

Its about separation of concerns and opt-in to volunteer to certain
areas by being *responsible* to do so. All the mentioned areas may have
different requirements and reasons to call for a potential veto.
Resigning or even getting booted of one of those doesn't forcefully mean
you can't or shouldn't still be in charge of other duties.

All this is about _how_ we establish separation of concerns and how we
avoid possible misuse of power but this is equally true to all the
already existing optional areas: Any position can be misused but that
neither means the _certain_ separation is bad nor does it mean it is
established to give a few folks power over others.

I agree iterating over sponsorship and co-maintaining will certainly
improve some of this. But I can as well imagine some "sub-duties" could
help to address the other problems. For time being I don't have a strong
opinion or idea how that exactly could look like but i can ensure it
shall indeed not be about power in any way described in this thread.

cheers,
Levente

-------------- 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/20181112/ef9d6af4/attachment.asc>