Provenpackager policy

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(replace page with approved policy)
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 (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.
 
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.
+
== Policy ==
  
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.
+
At the FESCo meeting on 2009/03/06, it was decided that the provenpackager group would be emptied and only existing sponsors would automatically gain admittance, as they had already been vetted by FESCo. This took place on Monday, 2009/03/08. Any future sponsor would also be added to the group if not already a member.
  
== Solution Overview ==
+
Any non-sponsor member of provenpackager would need to follow the below procedure in order to gain membership.
Multiple provenpackager/provenpackage-sponsor-votes should be required to allow a packager into the provenpackagers group.
+
  
== Scope ==
+
* Make desire known to [[Development/SteeringCommittee|FESCo]]. This can be done in any fashion - private mail to the chair, on [https://www.redhat.com/mailman/listinfo/fedora-devel-list fedora-devel-list], via IRC (probably not really recommended), via mail to fedora-extras-steering@redhat.com, filing a ticket at the [https://fedorahosted.org/fesco Trac] instance, applying to the group, carrier pigeon, etc. It is helpful if you specify what you plan to do with the access in the communication.
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.
+
* If reason for access is not stated, the FESCo chair may ask for clarification from the individual requesting access what they plan to do with the access.
 
+
* The FESCo chair will send an e-mail to the sponsors list for the packager group. Debate will take place on the list for a perriod of one week normally.
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.
+
* FESCo will vote at it's weekly meeting on the proposals.
 
+
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 [[Talk:PackageMaintainers/ProvenpackagerProposal|the talk page]].
+
  
 
[[Category:Package Maintainers]]
 
[[Category:Package Maintainers]]

Revision as of 05:24, 11 March 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.

Policy

At the FESCo meeting on 2009/03/06, it was decided that the provenpackager group would be emptied and only existing sponsors would automatically gain admittance, as they had already been vetted by FESCo. This took place on Monday, 2009/03/08. Any future sponsor would also be added to the group if not already a member.

Any non-sponsor member of provenpackager would need to follow the below procedure in order to gain membership.

  • Make desire known to FESCo. This can be done in any fashion - private mail to the chair, on fedora-devel-list, via IRC (probably not really recommended), via mail to fedora-extras-steering@redhat.com, filing a ticket at the Trac instance, applying to the group, carrier pigeon, etc. It is helpful if you specify what you plan to do with the access in the communication.
  • If reason for access is not stated, the FESCo chair may ask for clarification from the individual requesting access what they plan to do with the access.
  • The FESCo chair will send an e-mail to the sponsors list for the packager group. Debate will take place on the list for a perriod of one week normally.
  • FESCo will vote at it's weekly meeting on the proposals.