From Fedora Project Wiki
No edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 43: Line 43:
Sponsors mentor new packagers through the review process to initial package submission, updates and and beyond until they are comfortable in working with the Fedora package maintenance systems.  Sponsors are expected to do the actual initial package reviews for those they sponsor in the case that the package submission process (as opposed to the comaintainership process) is being followed.
Sponsors mentor new packagers through the review process to initial package submission, updates and and beyond until they are comfortable in working with the Fedora package maintenance systems.  Sponsors are expected to do the actual initial package reviews for those they sponsor in the case that the package submission process (as opposed to the comaintainership process) is being followed.


Sponsors should expect to sponsor one person per year, assuming there are sufficient new packagers who require sponsorship to fulfill this requirement.  (Who am I kidding?  If we get the number down that low we can all celebrate.)
Sponsors should expect to participate in the review of at least one NEEDSPONSOR ticket per year, assuming there are sufficient new packagers who require sponsorship and sufficient packages within the realm of expertise of the sponsor to fulfill this requirement.  (Who am I kidding?  If we get the number down that low we can all celebrate.)


Sponsorship status is gained by meeting the requirements above, and making a request to the sponsors (via trac, perhaps).  Votes will be taken from the sponsors in the usual +1/-1 fashion and totaled; If the total is at least +3 then the applicant is made a sponsor.
Sponsorship status is gained by meeting the requirements above, and making a request to the sponsors (via trac, perhaps).  Votes will be taken from the sponsors in the usual +1/-1 fashion and totaled; If the total is at least +3 then the applicant is made a sponsor.


Loss of sponsorship is automatic if the account goes inactive or is disabled (in FAS terminology). It can always be requested again.
Loss of sponsorship is automatic if, in FAS terminology the account goes inactive or is disabled(This generally happens only if the user does not deal with mandatory password changes.)  It can always be requested again.


== Sponsor activity report ==
== Sponsor activity report ==

Latest revision as of 19:17, 27 April 2012

Revitalizing the sponsorship model

The sponsorship model we have is fundamental to the success of our packaging efforts. With bugzappers and even infrastructure, interested people can just drop by, introduce themselves and join up. The packager group has a vastly higher barrier to entry; users have to go through an almost endless set of steps (which also needs revision, but that's another topic) and then pin their hopes on a review ticket that, due to an insufficient number of active sponsors, may not get looked at in a reasonable amount of time. (See activity report at the end for some data.) This really needs to change.

For some time I've been troubled by several problems (as I see them) with the current sponsorship model:

  • Sponsors don't really do anything except occasionally sponsor (obviously) and perhaps provide advisory commentary on new sponsors. There's no identity to the group.
  • We have no criteria for becoming a sponsor.
  • We are restrictive in granting sponsor status because it implies provenpackager when really it's about mentoring.
  • There are no requirements for staying a sponsor; we have 102 sponsors but most don't sponsor anyone.

It seems to me that some relatively modest solutions (or at least partial solutions) exist to these.

  • Give sponsors some duties and the means to coordinate them.
  • Lay out what is expected of sponsors and lay out some soft criteria which attempt to capture the set of people who can do that.
  • Sever the provenpackager/sponsor relation.
  • Make some criteria that sponsors need to meet if they wish to remain sponsors.

I am volunteering to do any work involved in making this happen as well as modifying existing policy documents and drafting successor policies in the event that these proposals are accepted by FESCo.

My proposals

Note first that I've chosen what I believe to be reasonable values for things like number of reviews to be done or number of votes necessary. I'm certainly happy to listen to alternatives.

FESCo should to delegate the elevation of packagers to sponsors (with FESCo oversight and possibility of override, as usual). FESCo should delegate to the sponsors the sponsorship portion of the comaintainer path (though obviously any sponsor can already do this). FESCo and should additionally delegate the removal of sponsorship status to the sponsors.

To facilitate this there should be some means for coordination, either a real mailing list for sponsor discussion or a trac or both. (It may be reasonable to use the fedora-packaging list for this but I'm concerned about overloading it.) The existing sponsor alias is insufficient because not only is it not archived but there is no way to join it without actually being a sponsor. The list could be used for new packager introductions as the other groups are doing. I think there should also be occasional sponsor meetings. This would all permit coordination and provide an avenue for monitoring of the sponsorship queue and the possible division of duties.

We should stop having sponsor imply provenpackager and instead grant sponsors access to the packages of those they sponsor. Granting provenpackager when someone is given sponsor status is currently a manual process so removing that link is trivial. Giving sponsors access to the packages of those they sponsor through the review process is actually a simple matter: just make sponsors comaintainers. They can watch commits, make sure things are going OK and then remove themselves from the packages once they believe things to be running smoothly. This also makes more clear the currently implied idea that sponsors should at least clean up after the people they sponsor in the unlikely event that they make a mess or disappear. This requires modification only to the SCM request procedure, though I can possibly make the SCM processing utility take note of the situation.

Note: This does not imply that provenpackager privileges will be removed from any existing sponsor. These changes only apply to new sponsors. This also doesn't require any changes to the sponsorship-through-comaintainership process, since there's already an experienced packager watching over the package.

Given that, I propose the following set of criteria and responsibilities, which I believe are quite simple and have the potential for greatly expanding the pool of sponsors.

Prospective sponsors should:

  • have been packagers for six months (so they've seen the entire release process, including branching)
  • own at least three packages (so they're ostensibly familiar with the process of importing packages and pushing updates)
  • have done five high-quality, non-trivial package reviews (so they have intimate familiarity with the review process).

The final requirement is a bit vague to allow for discussion and to make voting reasonable; otherwise an automated system could simply auto-elevate packagers to sponsors.

Sponsors mentor new packagers through the review process to initial package submission, updates and and beyond until they are comfortable in working with the Fedora package maintenance systems. Sponsors are expected to do the actual initial package reviews for those they sponsor in the case that the package submission process (as opposed to the comaintainership process) is being followed.

Sponsors should expect to participate in the review of at least one NEEDSPONSOR ticket per year, assuming there are sufficient new packagers who require sponsorship and sufficient packages within the realm of expertise of the sponsor to fulfill this requirement. (Who am I kidding? If we get the number down that low we can all celebrate.)

Sponsorship status is gained by meeting the requirements above, and making a request to the sponsors (via trac, perhaps). Votes will be taken from the sponsors in the usual +1/-1 fashion and totaled; If the total is at least +3 then the applicant is made a sponsor.

Loss of sponsorship is automatic if, in FAS terminology the account goes inactive or is disabled. (This generally happens only if the user does not deal with mandatory password changes.) It can always be requested again.

To back up some assertions, I did some diving through the FAS database.

We currently have 102 sponsors. Currently five of those are marked inactive or disabled in FAS. (For comparison, there are 1176 packagers, with 101 of them inactive or disabled.) At first glance, that would seem to be a reasonable ratio and I believe it would be if all of the sponsors were active.

Of the 102 sponsors, 14 have never sponsored anyone. Of the remaining 88, 42 have not sponsored anyone in the past year.

This gives us a pool of 46 active sponsors (where "active" obviously means "has sponsored someone in the past year). Most of them (34) have sponsored someone within the past six months.

This rate of activity has been unable to reduce the set of needsponsor requests, which has currently stands at 121. Obviously this list will be never be completely emptied as there will always be unreviewable or stalled requests.

I have no statistics on the average wait time of NEEDSPONSOR tickets, but in recent review work I've encountered several tickets with active submitters waiting for as long as 16 months. I also have no statistics on the rate of new NEEDSPONSOR tickets. (Generating useful statistics from bugzilla is difficult.)

Even with this small amount of data, it appears that my concern is justified. While the pool of active sponsors is actually quite a bit larger than I originally thought, it's still not enough to ensure that prospective packagers have their tickets reviewed in a reasonable amount of time.