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
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 and perhaps provide advisory commentary on new sponsors.
- We have no criteria for becoming a sponsor.
- We are restrictive in granting sponsor status because it implies provenpackager.
- 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.
- 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.
I will work with administrators to generate some basic reports; I'd at least like to know whether each of the 102 sponsors has sponsored anyone within the last N years/months and whether they're even still active in the project.
FESCo should delegate the elevation of sponsors to the sponsors (with FESCo oversight and possibility of override, as usual). FESCo should also delegate to the sponsors the sponsorship portion of the comaintainer path (though obviously any sponsor can already do this). 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.
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.
I propose the following language for the duties of a sponsor:
- 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.
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).
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.