(Created page with "Brainstorm for revitalizing sponsorship: Problem: No data on who is doing what. Solution: Reports/data mining. 102 sponsors currently. How many have sponsored anyone in the p...") |
No edit summary |
||
| Line 6: | Line 6: | ||
Solution: | Solution: | ||
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? | 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? | ||
Proposal: | |||
Work with administrators to generate some basic reports. | |||
Problem: | Problem: | ||
Sponsors don't really do anything except occasionally sponsor and perhaps provide advisory commentary on new sponsors | Sponsors don't really do anything except occasionally sponsor and perhaps provide advisory commentary on new sponsors. | ||
Solution: | Solution: | ||
Actually give the sponsors duties and the means to coordinate them. | |||
Proposal: | |||
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. | This would 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 sponsors. Work up some means to give sponsors access to sponsoree packages. | |||
Problem: | Problem: | ||
| Line 18: | Line 27: | ||
Solution: | Solution: | ||
First define what sponsors are expected to do | 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. | ||
Proposal: | |||
Sponsors mentor new packagers through the review process and beyond until they are comfortable with the entire system, including updates. | |||
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. (Needs modification for the comaintainer path.) | |||
Problem: | Problem: | ||
| Line 24: | Line 40: | ||
Solution: | Solution: | ||
Make some. | Make some. | ||
Proposal: | |||
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 16:57, 19 April 2012
Brainstorm for revitalizing sponsorship:
Problem: No data on who is doing what.
Solution: 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?
Proposal: Work with administrators to generate some basic reports.
Problem: Sponsors don't really do anything except occasionally sponsor and perhaps provide advisory commentary on new sponsors.
Solution: Actually give the sponsors duties and the means to coordinate them.
Proposal: 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.
Sever the packager < provenpackager < sponsor ordering so we can not fret about giving so much access to sponsors. Work up some means to give sponsors access to sponsoree packages.
Problem: No criteria for becoming a sponsor.
Solution: 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.
Proposal: Sponsors mentor new packagers through the review process and beyond until they are comfortable with the entire system, including updates.
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. (Needs modification for the comaintainer path.)
Problem: No criteria for staying a sponsor.
Solution: Make some.
Proposal: 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.