Jump to: navigation, search

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 4 users 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 07: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.

See Also