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

2018-11-12 Thread Santiago Torres-Arias via aur-general
Hi,
 
> 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.

Agreed. If the term for the council was changed to "working groups"
would that be better?

>
> 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.

Agreed. I personally don't want to add more power to certain users over
others, and I think that's what the general consensus is leaning
towards...

-Santiago.


signature.asc
Description: PGP signature


Re: [aur-general] Package present in aur-git, but not in the aur

2018-11-12 Thread David Adler via aur-general



On November 11, 2018 3:20:11 PM UTC, pianoslum via aur-general 
 wrote:
...
>As I don't have much experience with packaging, I would be glad for any
>
>feedback!

provides=(elster) is superfluous. It would
be required, alongside conflicts=('elster'),
for a differently named VCS version like elster-git.
 
>Have a nice day!
Y'all too.


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

2018-11-12 Thread Levente Polyak via aur-general
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