[aur-general] On TU application, TU participation and community/ package quality
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: ## Issues * Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository. * The implication of some TUs in the distribution is very limited outside of packaging. ### current proposals (simplified) The discussion #archlinux-tu channel has yielded three general possibilities: 1. Add a council of TU's to introduce oversight on the whole voting process 2. Increase the minimum number of sponsors per application 3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately Consider that these need not be the only possibilities and any further proposals should be also brought up. ## Proposals ### TU council Creating a council of TUs who, by means of experience and involvement, make sure the approval of new TU's is properly reviewed. As such, this council will be in charge of voting in and/or sponsoring a new TU applicant. This raises questions about the horizontal power structure of the TU community. The consequences of bringing a hierarchy like this need to be discussed, as more than one TU is concerned of the implications of this model. The means for election for such a council are yet to be discussed, as the feasibility of this measure is to be discussed first. ### Minimum number of sponsors An alternative to a TU council is to increase the minimum number of sponsors for a TU application. This has been the case in other communities that experienced rapid growth (e.g., CNCF) and may help increase oversight and preparation of newer applicants. Variants of this model can be considered too. For example, a buddy system in which new applicants need both an experienced TU and a new TU as sponsors may also help preparing new TU's with the process of preparing applicants. However, one question raised during the discussion is whether this model is enough to warrant the goals outlined above. Namely, this measure doesn't seem to tackle the lack of participation of the broader TU community when reviewing new TU applications. ### Oversight committee Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes. The methods by which this committee would enforce better TU participation are still to be discussed, but issuing warnings and probably bring cases to the broader TU community regarding an underperforming TU may be sufficient and nondisruptive. ## Conclusions The proposals above serve as a first step to discuss and iteratve over ideas on how to improve TU participation, applications and package quality. With this in mind, discussion of the applicability of these (or any other proposal) alone or on tandem should follow suit. Thanks! -Santiago P.S.: sorry for the legalose tone. I've probably spent too much time this week going through governance documents for different communitites. P.S.: Some of the ideas put forward is my interpretation of the text after going through the irc logs. Please correct me if my interpretation is wrong or incomplete. * e.g., reviewing PKGBUILDs or going through AUR requests
On Sun, Nov 11, 2018 at 01:29:31PM -0500, Discussion about the Arch User Repository (AUR) 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:
## Issues
* Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository. * The implication of some TUs in the distribution is very limited outside of packaging.
### current proposals (simplified)
The discussion #archlinux-tu channel has yielded three general possibilities:
1. Add a council of TU's to introduce oversight on the whole voting process 2. Increase the minimum number of sponsors per application 3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately
Consider that these need not be the only possibilities and any further proposals should be also brought up.
## Proposals
### TU council
Creating a council of TUs who, by means of experience and involvement, make sure the approval of new TU's is properly reviewed. As such, this council will be in charge of voting in and/or sponsoring a new TU applicant.
This raises questions about the horizontal power structure of the TU community. The consequences of bringing a hierarchy like this need to be discussed, as more than one TU is concerned of the implications of this model.
The means for election for such a council are yet to be discussed, as the feasibility of this measure is to be discussed first.
### Minimum number of sponsors
An alternative to a TU council is to increase the minimum number of sponsors for a TU application. This has been the case in other communities that experienced rapid growth (e.g., CNCF) and may help increase oversight and preparation of newer applicants.
Variants of this model can be considered too. For example, a buddy system in which new applicants need both an experienced TU and a new TU as sponsors may also help preparing new TU's with the process of preparing applicants.
However, one question raised during the discussion is whether this model is enough to warrant the goals outlined above. Namely, this measure doesn't seem to tackle the lack of participation of the broader TU community when reviewing new TU applications.
### Oversight committee
Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes.
The methods by which this committee would enforce better TU participation are still to be discussed, but issuing warnings and probably bring cases to the broader TU community regarding an underperforming TU may be sufficient and nondisruptive.
## Conclusions
The proposals above serve as a first step to discuss and iteratve over ideas on how to improve TU participation, applications and package quality. With this in mind, discussion of the applicability of these (or any other proposal) alone or on tandem should follow suit.
Thanks! -Santiago
P.S.: sorry for the legalose tone. I've probably spent too much time this week going through governance documents for different communitites.
P.S.: Some of the ideas put forward is my interpretation of the text after going through the irc logs. Please correct me if my interpretation is wrong or incomplete.
* e.g., reviewing PKGBUILDs or going through AUR requests
Hello Santiago, First of all thanks for rewriting this up: https://lists.archlinux.org/pipermail/arch-dev-public/2018-November/029392.h... I have a few questions about your oversight comittee. You wrote:
Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes.
The methods by which this committee would enforce better TU participation are still to be discussed, but issuing warnings and probably bring cases to the broader TU community regarding an underperforming TU may be sufficient and nondisruptive.
When I understand this correctly you want to punish TUs when they don't fullfill their duties. How do you want to accomplish this and what do you mean with 'moving packages to and from the AUR whrn the package's popularity changes'? So only this commitee should be able to push new packages to [community]? Best regards, Chris
Hello Santiago,
First of all thanks for rewriting this up: https://lists.archlinux.org/pipermail/arch-dev-public/2018-November/029392.h...
No problem! Hope I didn't miss anything. I was wondering whether to post the link to this thread, thanks for that :)
I have a few questions about your oversight comittee. You wrote:
Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes.
The methods by which this committee would enforce better TU participation are still to be discussed, but issuing warnings and probably bring cases to the broader TU community regarding an underperforming TU may be sufficient and nondisruptive.
When I understand this correctly you want to punish TUs when they don't fullfill their duties. How do you want to accomplish this and what do you mean with 'moving packages to and from the AUR whrn the package's popularity changes'? So only this commitee should be able to push new packages to [community]?
"Punishing" was a word that I was avoiding. I wouldn't want this committee to be vested with power over TU's for obvious reasons. If at all, I would be proposing for them to: 1) Privately warn TUs when of any faults they are committing 2) Follow up publicly when the warnings are disregarded 3) Open a public case with the rest of the TU's to remove the offender, as it id describing in the bylaws[1] Cheers! -Santiago. [1] https://aur.archlinux.org/trusted-user/TUbylaws.html#_removal_of_a_tu
Santiago, thanks for writing up the discussion to date! On 11 Nov 2018, at 1:29 pm -0500, Santiago Torres-Arias via aur-general wrote:
1. Add a council of TU's to introduce oversight on the whole voting process
Creating a council of TUs who, by means of experience and involvement, make sure the approval of new TU's is properly reviewed. As such, this council will be in charge of voting in and/or sponsoring a new TU applicant.
This raises questions about the horizontal power structure of the TU community. The consequences of bringing a hierarchy like this need to be discussed, as more than one TU is concerned of the implications of this model.
I'm pretty new to the whole TU thing, but I'm a little leery of this idea for a few reasons. As you mention, there are power dynamics at play once you start getting into things like this. Perhaps more importantly to the discussion at hand, I would also argue that such a set-up would do little to take the load off of the handful of high-participation TUs; if anything, I can see it *adding* to their load by formalizing their ad-hoc status.
2. Increase the minimum number of sponsors per application
This could be helpful, particularly when it comes to giving advice to newly-appointed TUs.
However, one question raised during the discussion is whether this model is enough to warrant the goals outlined above. Namely, this measure doesn't seem to tackle the lack of participation of the broader TU community when reviewing new TU applications.
Granted. With any luck, this very discussion will help *some* with that issue, but if we go with proposal 2, perhaps participation issues could be handled as a separate problem altogether. I know that, personally, I almost never participate in new candidate discussions simply because I don't feel I have anything to add.
3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately
Finally, a third proposal (and the one I'm championing) is to generate an elected organism within the TU community to overlook the performance of Trusted Users on the duties they agreed to fulfill. This oversight committee would track the activities of individual TUs and ensure that they are in fact participating in reviews, submitting proper high-quality PKGBUILDS, and moving packages to and from the AUR when the package's popularity changes.
I'm pretty conflicted about this idea, to be honest. Although I'm all for having some sort of oversight, the cynic in me forsees all kinds of problems even if you assume that all parties involved are acting in good faith (which I do choose to assume here). Even given the existence of TU guidelines, we would probably need to set up some very specific, enforceable rules in order for this to be at all workable. Would there need to be a participation quota? How strict do we really want to be about package popularity? Whose idea of "high-quality" are we using? Unless there are definite answers, we're right back where we started, with a set of guidelines to be played by ear--but now with the added overhead of a subcommittee structure. Personally, I'm inclined toward simply increasing the number of sponsors and encouraging sponsors to help their candidates learn the ropes of proper Trusted Using. If nonparticipation continues to be a problem, that can be a separate discussion. Cheers, Ivy
The oversight committee seems like an even more imposing version of the council, which has already received a fair amount of push-back. For example, a buddy
system in which new applicants need both an experienced TU and a new TU as sponsors may also help preparing new TU's with the process of preparing applicants.
However, one question raised during the discussion is whether this model is enough to warrant the goals outlined above. Namely, this measure doesn't seem to tackle the lack of participation of the broader TU community when reviewing new TU applications.
Big +1 here. This creates a bit of a cycle, and I believe would increase overall participation. Best, polyzen
On 11/11/2018 18:29, Santiago Torres-Arias via aur-general wrote:
* Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository.
This first bit is mainly rhetorical: If these issues are combined, one thing which comes to mind is how the hypothetical situation where a TU uploads damaging/malicious content would be dealt with. For example, is there already some sort of "quality threshold" below which TU status is removed and packaging keys revoked? If there's already a process in place does it currently work and, if so, why are changes necessary? On 11/11/2018 18:29, Santiago Torres-Arias via aur-general wrote:
1. Add a council of TU's to introduce oversight on the whole voting process 2. Increase the minimum number of sponsors per application 3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately
This bit is not rhetorical: I might float another option, whereby TU applicants would go through a "probationary phase". This could be accomplished by having PKGBUILD changes submitted by the would-be TU but approved (and packaged) by existing TUs, e.g. the sponsor(s). I haven't used cgit enough to know how merge requests work there, but certainly with GitHub and GitLab (and Gitea etc.) PRs provide for a level of approval before being allowed to be merged.* This would allow quality issues to be caught and addressed before the packages hit the repos, and provide evidence to support a "full" TU status. I suspect that sort of review could also be shared as necessary, so any TU or developer can keep an eye on the process to make sure it's being done correctly. That might also combine nicely with number 3. * (Thinking about a naïve implementation; if a web-accessible PR system was useful and can't be done via cgit it could possibly be accomplished via a intermediary "mirror", e.g. Gitea mirrors the git.archlinux repo, applicants submit PRs against the mirror, sponsors approve and commit to git.archlinux)
On Sun, 2018-11-11 at 13:29 -0500, Santiago Torres-Arias via aur-general wrote:
## Issues * Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. Do you have several example to show? * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. From which facts are this assumption is built from? * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository. Idem. What elements do you have to support this feeling ? * The implication of some TUs in the distribution is very limited outside of packaging. What's wrong with that? Regards,
Sébastien "Seblu" Luttringer
On Sun, Nov 11, 2018 at 01:29:31PM -0500, Santiago Torres-Arias via aur-general wrote:
### TU council
I'll summarize this with: I'm unsure. This feels like smacking a social problem with a hammer. I'm also afraid of power imbalance as Ivy have noted. I think we should refocus this effort into something else. Explained below.
### Minimum number of sponsors
I like this idea as a minimum amount of sponsorships. This could also help getting the new TUs up to speed with how things work. This could combine well with Jonathons suggestions of a "probation phase" (Which we have anyway since key signing takes *AGES*). This could also fit well with having co-maintainers? The sponsors should co-maintain the packages the applicant adopts from AUR?
### Oversight committee
I think we should refocus this effort into something simpler; clarifying package guidelines and actually make it easy for existing TUs to figure out *HOW* to package different ecosystems. This could also contribute to removing old habits. I have spent some hours upgrading out Go and Python guidelines to comfort to something we can understand, agree on and doesn't forward bad habits from old PKGBUILDs. A lot of knowledge is implicit, or just derived second-hand from people that are presumed to know things. What happens if those people disappear tomorrow? How is the committee suppose to define a `high-quality PKGBUILD` if we can't distinguish peoples strong subjective opinions from factualities. -- Morten Linderud PGP: 9C02FF419FECBE16
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:
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...
* 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? 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.
* 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. On a more practical note: when some people are so active that they reply to any question on [aur-general] almost immediately, you just can't be faster unless you watch your Arch emails all day long. So maybe some TUs need to participate more, but conversely some TUs might also need to leave a bit of room for the others! One area where more contributions would be welcome is handling AUR requests [1]. But as far as I can tell, we currently don't even advertise this to new TUs [2]. Baptiste [1] https://aur.archlinux.org/requests/ [2] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
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
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.
On Sun, Nov 11, 2018 at 11:10 PM Sébastien Luttringer via aur-general < aur-general@archlinux.org> wrote:
## Issues * Existing Trusted Users are not followed closely in their actions, and
quality of some packages for instance is more than questionable. Do you have several example to show? * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. From which facts are this assumption is built from? * There is a general feeling of decreasing/not high enough quality in
On Sun, 2018-11-11 at 13:29 -0500, Santiago Torres-Arias via aur-general wrote: the the
packages provided in the community/ repository. Idem. What elements do you have to support this feeling ? * The implication of some TUs in the distribution is very limited outside of packaging. What's wrong with that?
+1 to all of this. Some contribute more, others less, and in different ways. My impression has always been that this is totally fine as long as quality doesn't suffer. Not all TUs need to have hundreds of packages and IRC / forum presence. Found a bad or outdated package? Prepare a new PKGBUILD and send a quick mail to the owner. Think someone shouldn't be a TU? There are processes in place for that. Votes have an 'abstain' option. That should be the logical vote if one does not have a strong opinion / enough information. IMHO there's really no need for governance structures.
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
On Sun, Nov 11, 2018 at 01:29:31PM -0500, Santiago Torres-Arias via aur-general wrote:
On TU applications, TU participation and package quality: everythign snipped
I just wanted to bump this thread. It appears to me that bumping the minimum number of TU sponsors + a buddy system would be the way to go? Should we move on to formalize this? Thanks, -Santiago.
Le 27/11/2018 à 16:32, Santiago Torres-Arias via aur-general a écrit :
On Sun, Nov 11, 2018 at 01:29:31PM -0500, Santiago Torres-Arias via aur-general wrote:
On TU applications, TU participation and package quality: everythign snipped I just wanted to bump this thread.
It appears to me that bumping the minimum number of TU sponsors + a buddy system would be the way to go?
Should we move on to formalize this?
Thanks, -Santiago.
I like part of Xyne ideas, that finally are just what good common sense should be: – The need to know who you sponsor a while before letting them apply; – The need to advocate for your candidate; – The need of several sponsors (maybe 2 should be enough if they are well chosen), but I would say beforehand, in order to have at least 2 reviews of the applicant PKGBUILDs before actually applying. And one of the sponsors should have been there for at least some years (not sure what would be a good number, 3, 5?). Regards, Bruno
Third-party non-involved user chiming in, but I do not think any sort of tenure/seniority requirement as mentioned in the final point below would be a good idea. Something based on recent activity would be better. On Wed, Nov 28, 2018 at 1:38 AM Bruno Pagani via aur-general < aur-general@archlinux.org> wrote:
Le 27/11/2018 à 16:32, Santiago Torres-Arias via aur-general a écrit :
On Sun, Nov 11, 2018 at 01:29:31PM -0500, Santiago Torres-Arias via aur-general wrote:
On TU applications, TU participation and package quality: everythign snipped I just wanted to bump this thread.
It appears to me that bumping the minimum number of TU sponsors + a buddy system would be the way to go?
Should we move on to formalize this?
Thanks, -Santiago.
I like part of Xyne ideas, that finally are just what good common sense should be:
– The need to know who you sponsor a while before letting them apply; – The need to advocate for your candidate; – The need of several sponsors (maybe 2 should be enough if they are well chosen), but I would say beforehand, in order to have at least 2 reviews of the applicant PKGBUILDs before actually applying. And one of the sponsors should have been there for at least some years (not sure what would be a good number, 3, 5?).
Regards, Bruno
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
On 2018-11-28 20:10:52 (+0100), Robin Broda via aur-general wrote:
On 11/18/18 3:52 AM, Xyne wrote:
On 2018-11-12 12:22 +0100 Levente Polyak via aur-general wrote:
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.
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.
Should we get these points formalized in the bylaws? I think so.
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. I agree with that and generally like the ideas put forward by Xyne (in extension of what Levente wrote). Having them separetely votable is preferable I guess.
I see, that we need more participation in the voting and reviewing process and I think that a more formalized rule set can help in doing so (and not just having one or two people do the review and then feeling overwhelmed at some point). I also think, that this has the potential to raise the overall package quality (aka teamwork) and help TUs across the board to learn new things. I don't believe in a separate gremium, that will magically fix this. Some TUs are exactly that involuntarily already (e.g. by choosing to review) - or at least it somewhat feels like it ;-) However, no single person can and or should do that all the time.
What are your thoughts? Let's do it!
Best, David -- https://sleepmap.de
On Wed, 2018-11-28 at 20:10 +0100, Robin Broda via aur-general wrote:
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. Lot of questions asked, few answered. Like those in my mail. New side proposals was suggestion by several people, I don't know how you can see who is agreeing on what.
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. Split will also help to understand the potential benefit of each change and if there is a real problem behind.
Regards, Sébastien "Seblu" Luttringer
participants (15)
-
Baptiste Jonglez
-
Bruno Pagani
-
Christian Rebischke
-
Daniel Capella
-
David Runge
-
Ivy Foster
-
Jakob Gruber
-
Jonathon Fernyhough
-
Levente Polyak
-
Morten Linderud
-
Oon-Ee Ng
-
Robin Broda
-
Santiago Torres-Arias
-
Sébastien Luttringer
-
Xyne