On 4/4/23 08:52, Otto Liljalaakso wrote: > Benson Muite kirjoitti 4.4.2023 klo 7.02: >> May >> also want to automatically track unofficial reviews by prospective >> packagers, perhaps even requiring a certain number of unofficial reviews >> for the sponsorship process to start. > > Yes, I think that the sponsorship process should be made more rigid, > with at least somewhat formally defined requirements. Maybe something > along the lines "do N unofficial package reviews AND submit M pull > requests to packages and get them merged AND convince a sponsor". The > current approach where "convince a sponsor" is the only actual > requirement creates unfortunate bias: > Pull requests are less easy to judge and vary significantly in complexity. It helps to judge, in particular since it is one way to help maintain a package. They can be used in assessing, but fixing a number of these as a requirement is difficult. They may also take time to merge. > 1. The easiest way to get in is to know somebody who is already in. This > is basically the opposite of how I understand "open community". > This is true. > 2. Applicants who find it easy to engage with unknown people in higher > community standing and have high confidence in their abilities navigate > the (ill-defined, unclear) process much easier than more cautious types. > Such character traits are of course very useful when participating in > open source communities, but discriminating other kinds of personality > leads to fewer contributors and lost talent. And it is, well, > discriminatory, thus not very ethical in my opinion. > > Another thing that can be improved here is to make it much less > necessary to even get packager status. Working with pull requests should > be the norm. Perhaps new package requests could more often be handled in > a way where an existing packager assumes the maintainer position with > the agreement that the submitter keeps the packager updated and in good > condition, through pull requests. The packager status should be just an > optional thing you can apply at some point in your Fedora contributor > career, *if* a situation demanding that occurs - much like packager > sponsor, provenpackager or even FESCo member status is, or how in > upstream projects there often are prominent contributors that take part > in the conversation and submit pull requests, without any commit access. > Response times to pull requests can vary. Most people who want to be packagers are submitting something new. The above would work well for SIGS which package related software. In particular, if a package can be adopted by a SIG, then the person submitting it need not be sponsored to have the package in Fedora, as the SIG can adopt the package, and the person submitting it make pull requests to make changes. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
