Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Google Summer of Code 2008 improvements"
(New page: =Some thoughts about the programme for next year== Maintaining an Eclipse projects for SOC is a rather poor fit with the Eclipse development process. For 2008, we should consider (note th...) |
|||
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | =Some thoughts about the programme for next year | + | =Some thoughts about the programme for next year= |
Maintaining an Eclipse projects for SOC is a rather poor fit with the Eclipse development process. | Maintaining an Eclipse projects for SOC is a rather poor fit with the Eclipse development process. | ||
Line 15: | Line 15: | ||
The short version is that GSoC students should not be treated any different than other committers. | The short version is that GSoC students should not be treated any different than other committers. | ||
+ | |||
+ | This is good because: | ||
+ | *Students experience the real Eclipse process. | ||
+ | *It doesn't screw up our process, or reinforce dangerous precedence for bending the rules. | ||
+ | *Lowers dependence on Eclipse Foundation infrastructure to get projects going. | ||
+ | |||
+ | This is bad because: | ||
+ | *Will really only work if mentors are already Eclipse committers. | ||
+ | *Mentors become a bottleneck for getting code committed (though this is probably not necessarily a problem) | ||
+ | |||
+ | It may seem a little elitist, but it's probably reasonable for us to require that mentors be Eclipse committers. | ||
+ | |||
+ | * Send out project related literature after acceptance of an application/beginning of the term [http://dev.eclipse.org/mhonarc/lists/soc-dev/msg00081.html (related soc-dev discussion)] | ||
+ | |||
+ | =See Also= | ||
+ | |||
+ | * [http://www.eclipse.org/projects/slides/GSoC_CreationReview.pdf Creation Review Slides] | ||
+ | * [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197059 Discussion & Review Vote] | ||
+ | * [[Google Summer of Code 2008 Ideas]] | ||
+ | |||
+ | [[Category:SOC]] |
Latest revision as of 08:31, 22 April 2008
Some thoughts about the programme for next year
Maintaining an Eclipse projects for SOC is a rather poor fit with the Eclipse development process.
For 2008, we should consider (note that these are just ideas for discussion):
- SOC Students must be treated the same way as other committers.
- Specifically, they should be elected into the position and are subject to the same requirements
- If a student's work is related to an existing project, they would follow the same process as anybody else
- Student contribute code through bugzilla like anybody else. That code can be put into CVS by a committer (possibly the mentor) assuming that it meets with standard requirements.
- Projects can set up an incubator if they deem it necessary.
- If, over time, the student demonstrates that they are a worthy committer, an election is held.
- If a student's work is not related to an existing project, then a separate home needs to be found
- For example, a Google Code project (which sort of makes sense)
- Over the term, the student can consider going through the proposal process to make their project into a real Eclipse project.
The short version is that GSoC students should not be treated any different than other committers.
This is good because:
- Students experience the real Eclipse process.
- It doesn't screw up our process, or reinforce dangerous precedence for bending the rules.
- Lowers dependence on Eclipse Foundation infrastructure to get projects going.
This is bad because:
- Will really only work if mentors are already Eclipse committers.
- Mentors become a bottleneck for getting code committed (though this is probably not necessarily a problem)
It may seem a little elitist, but it's probably reasonable for us to require that mentors be Eclipse committers.
- Send out project related literature after acceptance of an application/beginning of the term (related soc-dev discussion)