Swiping an idea from Ruby SOC, what do you all think about having 1/2 projects that are smaller in scope, designed to run in 1/2 the time of a full project, and have 1/2 of the stipend?
== full project ==
* ~10 weeks * Full scope * $5000
== half project ==
* ~5 weeks * Smaller scope * $2500
+1 I like the idea. This will give opportunity to take up smaller projects and will rescue those who have certain commitments during the holidays.
On Wed, Apr 21, 2010 at 8:43 PM, Karsten Wade kwade@redhat.com wrote:
Swiping an idea from Ruby SOC, what do you all think about having 1/2 projects that are smaller in scope, designed to run in 1/2 the time of a full project, and have 1/2 of the stipend?
== full project ==
- ~10 weeks
- Full scope
- $5000
== half project ==
- ~5 weeks
- Smaller scope
- $2500
-- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture uri: http://TheOpenSourceWay.org/wiki gpg: AD0E0C41
summer-coding mailing list summer-coding@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/summer-coding
On Wed, Apr 21, 2010 at 10:13 AM, Karsten Wade kwade@redhat.com wrote:
Swiping an idea from Ruby SOC, what do you all think about having 1/2 projects that are smaller in scope, designed to run in 1/2 the time of a full project, and have 1/2 of the stipend?
+1 here, though I would expect the full amount of effort for any mentor of such a project. There may be less to do, thus less code review, but helping get people involved in the larger community, communicating, providing advice, doing the mid- and end reviews etc. would remain unchanged.
On Wed, Apr 21, 2010 at 10:32:51AM -0500, Matt Domsch wrote:
On Wed, Apr 21, 2010 at 10:13 AM, Karsten Wade kwade@redhat.com wrote:
Swiping an idea from Ruby SOC, what do you all think about having 1/2 projects that are smaller in scope, designed to run in 1/2 the time of a full project, and have 1/2 of the stipend?
+1 here, though I would expect the full amount of effort for any mentor of such a project. There may be less to do, thus less code review, but helping get people involved in the larger community, communicating, providing advice, doing the mid- and end reviews etc. would remain unchanged.
+1 to that, too!
We'll have to put that in to the description. The producing part of the project (code, content) is the only part of the project that is cut in half. The how-to-be-part-of-a-FOSS-project is going to take the same effort.
- Karsten
On Wed, Apr 21, 2010 at 08:13:53AM -0700, Karsten Wade wrote:
Swiping an idea from Ruby SOC, what do you all think about having 1/2 projects that are smaller in scope, designed to run in 1/2 the time of a full project, and have 1/2 of the stipend?
== full project ==
- ~10 weeks
- Full scope
- $5000
== half project ==
- ~5 weeks
- Smaller scope
- $2500
One word of warning here -- even if the student has gotten acquainted with the project before the start of the five weeks, there's still some amount of time that they spend getting a feel for stuff. For instance, they may know who they're supposed to talk to and what the source code looks like but they may still not know how best to submit code for review. This kind of stuff will be fairly constant whether it's a full or half project so, proportionally, you have less time spent coding in the half project.
Another thought around this -- have we considered a formalized bounty system for small tasks? I think it takes quite a bit more work to organize since these need to have clearly defined deliverables, be a small enough chunk that you're never left wondering if the bounty is being fulfilled by the person who took it, and have enough of them that the students looking at them have adequate choice to choose from. But they seem to me to be a better method of organizing small tasks since they're very much about providing a deliverable rather than working on a feature specification where there's a question of whether partial work still deserves to be paid for.
I think the google highly open participation contest took this form: http://code.google.com/opensource/ghop/2007-8/
-Toshio
On Sun, Apr 25, 2010 at 11:11:30AM -0400, Toshio Kuratomi wrote:
One word of warning here -- even if the student has gotten acquainted with the project before the start of the five weeks, there's still some amount of time that they spend getting a feel for stuff. For instance, they may know who they're supposed to talk to and what the source code looks like but they may still not know how best to submit code for review. This kind of stuff will be fairly constant whether it's a full or half project so, proportionally, you have less time spent coding in the half project.
That's a fair point ... we might want to visualize half projects as being less than 1/2 of the coding to make up for this. Say, 1/3rd the coding of a full project?
Another thought around this -- have we considered a formalized bounty system for small tasks? I think it takes quite a bit more work to organize since these need to have clearly defined deliverables, be a small enough chunk that you're never left wondering if the bounty is being fulfilled by the person who took it, and have enough of them that the students looking at them have adequate choice to choose from. But they seem to me to be a better method of organizing small tasks since they're very much about providing a deliverable rather than working on a feature specification where there's a question of whether partial work still deserves to be paid for.
If you haven't seen OpenHatch.org, take a look. They are putting together a cross-project system for tracking such small/bite-sized projects. (It's also tied in to reputation building and such, so it has value for us and the student beyond just the getting things done.)
Some of us have been talking with OpenHatch on a few fronts:
* Getting a method to identify and scrape easy fix bugs from bugzilla.redhat.com
* Similar for small project needs from Fedora Hosted.
* Manual insertion of project pieces that made be or add up to a summer coding project.
There wasn't time to use OpenHatch for this season, but I'd like to see something happening perhaps by the fall for the next season.
- Karsten
summer-coding@lists.fedoraproject.org