From Fedora Project Wiki
No edit summary
No edit summary
Line 1: Line 1:
= Revitalizing the sponsorship model =
= 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 might not ever get looked at by anyone.  This really needs to change.
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.  This really needs to change.


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


* We have no data on what sponsors are doing what.
* 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.
* 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 have no criteria for becoming a sponsor.
Line 13: Line 12:
It seems to me that some relatively modest solutions (or at least partial solutions) exist to these.
It seems to me that some relatively modest solutions (or at least partial solutions) exist to these.


* Generate some reports.  See the activity report at the end.
* Give sponsors some duties and the means to coordinate them.
* 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.
* 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.
Line 25: Line 23:
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.
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 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.
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.


We should stop having sponsor imply provenpackager and instead grant sponsors access to the packages of their sponsorees.  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.
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 their sponsorees.  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 comaintainersThey 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.


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.
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.
Line 38: Line 38:
* have been packagers for six months (so they've seen the entire release process, including branching)
* 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)
* 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).  This requirement is intentionally vague, and it is not necessary
* have done five high-quality, non-trivial package reviews (so they have intimate familiarity with the review process).  This 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 their sponsorees in the case that the sponsoree is going through the package submission process as opposed to the comaintainership process.
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 their sponsorees in the case that the sponsoree is going through the package submission process as opposed to the comaintainership process.


Sponsors should expect to sponsor one person per time period (year?) to be considered active, 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.) Sponsorship status is gained by meeting the requirements above, making a request to the sponsors (via trac, perhaps) and gaining the concent of three existing sponsorsSponsorship status is lost by decision of sponsors/sponsor subcommittee/whatever after that point. Loss of sponsorship is automatic if the account goes inactive or is disabled.  (It can always be requested again.)
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.)
 
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.


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

Revision as of 20:51, 25 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. 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.

The first and possibly the fourth require technical work and coordination with infrastructure (for which I am volunteering); the rest are policy decisions.

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 their sponsorees. 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.

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). This 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 their sponsorees in the case that the sponsoree is going through the package submission process as opposed to the comaintainership process.

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.)

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.

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.