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