Difference between revisions of "Google Summer of Code 2008 improvements"

From Eclipsepedia

Jump to: navigation, search
(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...)
 
(Some thoughts about the programme for next year=)
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)

Revision as of 10:35, 17 July 2007

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)