User:Tibbs/RevitalizingSponsorshipProposal

From FedoraProject

< User:Tibbs(Difference between revisions)
Jump to: navigation, search
(Formatting)
Line 1: Line 1:
= Brainstorm for revitalizing sponsorship =
+
= Proposal for revitalizing the sponsorship model =
  
Here's some problems with the current sponsorship model and ideas for fixing it.
+
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
  
== No data on who is doing what ==
+
For some time I've been troubled by several problems (as I see them) with the current sponsorship model:
  
<b>Solution:</b>
+
* We have no data on what sponsors are doing what.
Reports/data mining. 102 sponsors currently. How many have sponsored anyone in the past N years/N months?  How many are still active in the project at all?
+
* 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.
  
<b>Proposal:</b>
+
It seems to me that some relatively modest solutions (or at least partial solutions) exist to these.
Work with administrators to generate some basic reports.
+
  
== Sponsors don't really do anything except occasionally sponsor and perhaps provide advisory commentary on new sponsors ==
+
* 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.
  
<b>Solution:</b>
+
== My proposals ==
Actually give the sponsors duties and the means to coordinate them.
+
  
<b>Proposal:</b>
+
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.
Delegate elevation of sponsors to the sponsors (with FESCo oversight and possibility of override, as usual).  Provide a real mailing list for sponsor discussion, maybe a ticketing system/trac in addition or instead.  (People don't always like yet another mailing list.)  Have occasional sponsor meetings.
+
  
This would permit coordination and provide an avenue for monitoring of the sponsorship queue and the possible division of duties.
+
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.  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.
  
Sever the packager < provenpackager < sponsor ordering so we can not fret about giving so much access to sponsorsWork up some means to give sponsors access to sponsoree packages.
+
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 trivialGetting 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.
  
== No criteria for becoming a sponsor ==
+
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.
  
<b>Solution:</b>
+
Given that, I propose the following criteria, which I believe are quite simple and have the potential for greatly expanding the pool of sponsors.
First define what sponsors are expected to do, then lay out some soft criteria which attempt to capture the set of people who can do that.
+
  
<b>Proposal:</b>
+
Prospective sponsors should:
Sponsors mentor new packagers through the review process and beyond until they are comfortable with the entire system, including updates.
+
* 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).
  
Prospective sponsors should have been packagers for six months (so they've seen the entire release process, including branching), should own at least three packages (so they're ostensibly familiar with the process of importing packages and pushing updates) and should 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 are expected to do the actual initial package reviews for their sponsorees.  (Needs modification for the comaintainer path.)
+
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.
 
+
== No criteria for staying a sponsor ==
+
 
+
<b>Solution:</b>
+
Make some.
+
 
+
<b>Proposal:</b>
+
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?)
+
 
+
Sponsorship status is lost by decision of sponsors/sponsor subcommittee/whatever after that point.
+

Revision as of 18:52, 19 April 2012

Proposal for 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.

My proposals

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