From Fedora Project Wiki
No edit summary
No edit summary
Line 8: Line 8:
* 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.
* We are restrictive in granting sponsor status because it implies provenpackager.
* 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. (This assertion needs data.)
* 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.
It seems to me that some relatively modest solutions (or at least partial solutions) exist to these.


* Generate some reports.
* 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 23: Line 23:
== My proposals ==
== My proposals ==


I have worked with infrastructure to generate some basic reports. I can now tell which sponsors have sponsored others and when they did so and am preparing a summary.
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 try to delegate the elevation of packagers to sponsors (with FESCo oversight and possibility of override, as usual).  I suggest "A packager may be made a sponsor with the consent of five existing sponsors".  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.  (I do recognize that people don't always want to join yet another mailing list but I also don't want to overload the packaging list.) 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..  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.


We should stop having sponsor implying 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 that part is trivial.  Getting the ACL setup correct outside of that could simply be done manually at SCM request time or could be done in some semi-automatic fashion at ACL generation time.  This requires more investigation and work with the infrastructure team.
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.


I propose the following language for the duties of a sponsor:
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.
* 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.


Given that, I propose the following criteria, which I believe are quite simple and have the potential for greatly expanding the pool of sponsors.
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.


=== Sponsor Criteria and Responsibilities ===
=== Sponsor Criteria and Responsibilities ===
Line 39: 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).
* 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


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 to zero we can all celebrate.)  Sponsorship 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 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 sponsors. Sponsorship 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.)
 
== Sponsor activity report ==
 
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.

Revision as of 20:23, 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 might not ever get looked at by anyone. This really needs to change.

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

  • Generate some reports. See the activity report at the end.
  • 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 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 intentionally vague, and it is not necessary

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

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.