Provenpackager policy

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Submitted my first FESco proposal for karma points needed to get a provenpackager)
 
(based on https://fedorahosted.org/fesco/ticket/833)
(16 intermediate revisions by 11 users not shown)
Line 1: Line 1:
= Karma needed to get Provenpackager =
+
Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. They are a group of skilled package maintainers who are experienced in a wide variety of package types and who are familiar with the [[Packaging:Guidelines|packaging guidelines]] and [[Package_maintainer_policy|package maintainer policies]], as well as acutely aware of [[Releases/Schedule|release schedule]] and [[ReleaseEngineering#Freeze_Policies|freeze policies]].
  
== Problem Space ==
+
Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora. Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in the policy explaining [[who is allowed to modify which packages]]. To exclude a package from provenpackagers access, you have to open a ticket at [https://fedorahosted.org/fesco/newticket FESCo issue tracker] and explain why provenpackagers should not have access to it. [[Fedora_Engineering_Steering_Committee | FESCo]] will discuss and vote on one of its weekly meetings about your request.
In the past, every regular Fedora packager having more than 5 packages (as maintainer) was able to request and get uberpackager, the later called provenpackager. This automagic way later got changed into manual FAS requests which can be approved by provenpackager (sponsors).
+
  
Currently only a single provenpackager (sponsor) is required in order to successfully sponsor a FAS request of a "regular" packager. This makes very easily slipping people in, that don't have that much experience and knowledge, a provenpackager (sponsor) should have.
+
== Becoming provenpackager ==
  
Normally, the provenpackager sponsor verifies whether it is clever to sponsor the FAS request or not, but if two people know each other on personal base, it is very easy, that a not advanced or less knowledged person maybe gets a provenpackager - a think, which shouldn't happen.
+
To become a member of the 'provenpackager' group, the procedure is the following:
 +
# File a ticket in the [https://fedorahosted.org/fesco FESCo issue tracker] indicating why you wish to become a provenpackager.
 +
# The FESCo chair will send an e-mail to the sponsors list for the packager group.
 +
# You must get at least 3 positive votes with no negative votes.
 +
# In case of negative votes, FESCo will vote at one of its weekly meetings on your request and then notify you if your request has been approved.
  
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 having a look how some package reviews are done, how packages are maintained or some package touchings are performed. Of course I'm referring here to individual cases I'm aware about, maybe some partiality of myself.
+
[[Category:Package Maintainers]]
 
+
[[Category:FESCo policy]]
== Solution Overview ==
+
Not just a single approval by a provenpackager (sponsor) should be required, but the approval of multiple ones.
+
 
+
== 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 definately 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 by time, more knowledged and so on, it can be changed +1 afterwards.
+
 
+
Maybe it's a clever thing here, to use the karma points as well to downgrade a person easily, if something goes horrible wrong. As minds and thinkings of provenpackagers (sponsors) can change, people can change as well and it would be inacceptable, if we can't revert a provenpackager same easy as we got one. So if the karma goes down below +15 karma points again, the person is degraded to a "regular" packager and loosing all provenpackager permissions. That idea/possibility should prevent us from getting harmed very easy.
+
 
+
This proposal makes necessary, that the current uberpackager/provenpackager list is completely reset and we're starting with an empty one having no legacy entries as we currently have.
+
 
+
Asking or 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 showing there up and is involved into processes already and knows how the wind blows. But the current situation is, that all of this is only "verified" by a single person (sponsor) and can't be reverted afterwards same easily 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? ==
+
Put in your comments, ideas and suggestions here, please.
+

Revision as of 09:25, 17 April 2012

Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. They are a group of skilled package maintainers who are experienced in a wide variety of package types and who are familiar with the packaging guidelines and package maintainer policies, as well as acutely aware of release schedule and freeze policies.

Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora. Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in the policy explaining who is allowed to modify which packages. To exclude a package from provenpackagers access, you have to open a ticket at FESCo issue tracker and explain why provenpackagers should not have access to it. FESCo will discuss and vote on one of its weekly meetings about your request.

Becoming provenpackager

To become a member of the 'provenpackager' group, the procedure is the following:

  1. File a ticket in the FESCo issue tracker indicating why you wish to become a provenpackager.
  2. The FESCo chair will send an e-mail to the sponsors list for the packager group.
  3. You must get at least 3 positive votes with no negative votes.
  4. In case of negative votes, FESCo will vote at one of its weekly meetings on your request and then notify you if your request has been approved.