Jump to: navigation, search

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

m (Some thoughts about the programme for next year)
(Some thoughts about the programme for next year)
Line 27: Line 27:
 
It may seem a little elitist, but it's probably reasonable for us to require that mentors be Eclipse committers.
 
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=
 
=See Also=

Revision as of 17:11, 12 September 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)

It may seem a little elitist, but it's probably reasonable for us to require that mentors be Eclipse committers.

See Also