(some re-phrasing) |
(Reviewed latest changes (thanks for your work)) |
||
Line 1: | Line 1: | ||
In the past, every regular Fedora packager having more than 5 packages (as maintainer) was able to request membership in the provenpackager group. This initial seeding of the group got changed into manual FAS requests later. Those requests can be approved by a single existing provenpackager-sponsor. | In the past, every regular Fedora packager having more than 5 packages (as maintainer) was able to request membership in the provenpackager group (former known as uberpackager group). This initial seeding of the group got changed into manual FAS requests later. Those requests can be approved by a single existing provenpackager-sponsor. | ||
The fact that a single person can decide over someone elses provenpacker-status makes it very easy to slip people in, which don't have the level of experience and knowledge that a provenpackager (sponsor) should have. | The fact that a single person can decide over someone elses provenpacker-status makes it very easy to slip people in, which don't have the level of experience and knowledge that a provenpackager (sponsor) should have. | ||
Line 17: | Line 17: | ||
We could also use the karma points as well to downgrade a person easily if something goes horrible wrong after he is approved. That way someone who doesn't prove to be eligible to the status of a provenpackager can be removed from the group via the same mechanism that is used to grant the status. So if the karma goes down below +15 karma points again, the person is degraded to a "regular" packager and looses provenpackager permissions. This should prevent us from getting harmed easily. | We could also use the karma points as well to downgrade a person easily if something goes horrible wrong after he is approved. That way someone who doesn't prove to be eligible to the status of a provenpackager can be removed from the group via the same mechanism that is used to grant the status. So if the karma goes down below +15 karma points again, the person is degraded to a "regular" packager and looses provenpackager permissions. This should prevent us from getting harmed easily. | ||
This proposal requires that the current provenpackager list is completely reset (and maybe seeded with all packager-sponsors and/or all packagers with more than | This proposal requires that the current provenpackager list is completely reset (and maybe seeded with all packager-sponsors and/or all packagers with more than 50 or so packages). | ||
Requiring more than a single person for a new provenpackager (and keeping that status) also ensures, that the person is somehow known to the Fedora community or at least to the packagers, is involved into processes already and knows how the wind blows. The current situation is, that all of this is only "verified" by a single person (sponsor) and can't be reverted later without making much noise. | Requiring more than a single person for a new provenpackager (and keeping that status) also ensures, that the person is somehow known to the Fedora community or at least to the packagers, is involved into processes already and knows how the wind blows. The current situation is, that all of this is only "verified" by a single person (sponsor) and can't be reverted later without making much noise. |
Revision as of 22:55, 28 January 2009
In the past, every regular Fedora packager having more than 5 packages (as maintainer) was able to request membership in the provenpackager group (former known as uberpackager group). This initial seeding of the group got changed into manual FAS requests later. Those requests can be approved by a single existing provenpackager-sponsor.
The fact that a single person can decide over someone elses provenpacker-status makes it very easy to slip people in, which don't have the level of experience and knowledge that a provenpackager (sponsor) should have.
Fedora currently has around 800 packagers, around 150 are provenpackagers - that's a lot. I can't imagine for myself, that we really have so many advanced and knowledged packagers, when looking at how some package reviews are done, how packages are maintained or some package-updates are performed. Of course I'm referring here to individual cases I'm aware about, maybe some partiality of myself.
Solution Overview
Multiple provenpackager/provenpackage-sponsor-votes should be required to allow a packager into the provenpackagers group.
Scope
Not just a single approval by a provenpackager-sponsor should be required, but the approval of multiple ones; maybe a voting or collecting karma points. What I definitely don't like to see is a voting where provenpackagers are bothered e.g. via e-mail or similar in order to vote for a new FAS request.
What I'm imaging is more or less the following scenario: A regular packager wants to get a provenpackager, thus he performs a FAS request for that. The provenpackagers maybe then notified, that a new provenpackager request went in as it currently is also the case, but that's optional. Provenpackagers now have a list in FAS with the person requesting provenpackager and can set a karma of -1/0/+1.
The scheme is similar to Bodhi, +15 karma points are required to get provenpackager. If a provenpackager doesn't vote or abstains, it's +/- 0, the default. And if a provenpackager is against the request, he can set -1. Provenpackagers are only allowed to give one vote/karma point in total, but should be able to change their mind later. If somebody makes to early a provenpackager request, it can be denied by setting -1, but if the person gets more and more involved and more knowledgeable over time, it can be changed +1 afterwards.
We could also use the karma points as well to downgrade a person easily if something goes horrible wrong after he is approved. That way someone who doesn't prove to be eligible to the status of a provenpackager can be removed from the group via the same mechanism that is used to grant the status. So if the karma goes down below +15 karma points again, the person is degraded to a "regular" packager and looses provenpackager permissions. This should prevent us from getting harmed easily.
This proposal requires that the current provenpackager list is completely reset (and maybe seeded with all packager-sponsors and/or all packagers with more than 50 or so packages).
Requiring more than a single person for a new provenpackager (and keeping that status) also ensures, that the person is somehow known to the Fedora community or at least to the packagers, is involved into processes already and knows how the wind blows. The current situation is, that all of this is only "verified" by a single person (sponsor) and can't be reverted later without making much noise.
Discussion Points
The number of karma points/votings which has to be required by provenpackager sponsors in order to get a provenpackager: Personally, I'm tending to 15 or even more positive points, but if really needed we can lower that to 10 positive points. That means, 10 provenpackager (sponsors) would have to accept the request of the "regular" packager using +1, and this seems to be a reasonable amount for me.
Comments?
Please place your comments, ideas and suggestions on the talk page.