RE: [soc-dev] Generalizing SOC

["Mik Kersten" <beatmik@xxxxxxx>]

There's been follow up on this in other threads already, but I just wanted
to mention that these ideas sound good to me Wayne.  I particular I like:

* Having a Bugzilla component for proposals, since this would allow the
Eclipse community to brainstorm and iterate on proposals and help students
browse past ideas.

* Not having the time box of just the summer around the project.  Mapping
the current project/subproject structure might be sufficient for handling
the lifecycle of individual students' projects.  If not perhaps components
could be used, but either way this would allow the Eclipse SOC project
committers to invest some time in an infrastructure that works from year to
year and maps gracefully onto the GSOC process.

Cheers,

Mik 

> -----Original Message-----
> From: soc-dev-bounces@xxxxxxxxxxx [mailto:soc-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Wayne Beaton
> Sent: Wednesday, August 15, 2007 7:07 PM
> To: Eclipse Summer of Code Mailing List
> Subject: [soc-dev] Generalizing SOC
> 
> I hope that everyone received my note about the project name and have
> been spending many thoughful hours coming up with new names.
> 
> I'd like to discuss the generalization of SOC beyond just the Google
> Summer of Code programme. Some of these thoughts have been captured in
> other spots; I thought that I'd try to bring them together on the
> mailing list. I'd love to hear from *everybody*, mentors and students.
> 
> To start with, we need to be careful about terminology. The word
> "project" has specific meaning in Eclipse-land, so we need to be
> careful
> about overloading it. Perhaps if we refer consistently to "student
> projects" that might work. I've been thinking of them as student
> "activities" as not everything that students do in this project will
> necessarily result in code being contributed to the project.
> 
> I see the SOC project as being a good place to host student work that
> doesn't fit elsewhere in Eclipse. Some students are working on fixing
> bugs or making contributions to other projects. These students don't
> need a CVS repository of their own. For students working on activities
> that don't fit, we can create a component in the project to both host
> their code and provide useful things like a bugzilla component. Of
> course any activity that results in code being stored in code being
> stored on our servers is subject to the full Eclipse Development
> Process
> (sorry, no GPL code...)
> 
> I don't see any reason why these components' lifespans need to be
> artificially time-boxed. The SOC project, so long as it remains
> vibrant,
> will not go away so we don't have to worry about it being archived so
> long as we continue to work on it.
> 
> I also don't see any value in putting the equivalent of a timestamp in
> a
> component name (e.g. "MyProject2007" or whatever). IMHO, a component
> name needs to be carefully selected. If we end up with conflicts in our
> component names, we'll have to sort out other workarounds. Ideally, we
> may get to a state where components are long-lived and get picked up
> year after year by new students. Or... we could end up with students
> offering to help other students (if you use the bugzilla system to keep
> track of what you're doing on your component, you may find that others
> want to help).
> 
> Over time, components should naturally either evolve or expire. Some
> may
> become their own Projects in Technology or elsewhere. Others may move
> to
> other projects. Some will just wither and die. Again, I'd rather not
> try
> to attach some kind of arbitrary lifespan.
> 
> The process of accepting projects is another area to consider. I'd like
> to see it done more in the open. We might, for example, have students
> propose their projects using a special "Proposal" component in SOC
> Bugzilla. There, we can all comment on it, ask for clarification and
> refinement, appeal to mentors to volunteer to help, and ultimately vote
> on whether or not the project is worth pursuing. For the Google Summer
> of Code projects, we can just transfer our results back to their system
> (and provide pointers back into our comment chain).
> 
> Just to be clear, I currently have no other sources of income for
> students wanting to participate. I know of a few students working on
> Eclipse-related projects as part of thesis and other project work who I
> am sure would love to have this sort of service regardless of whether
> or
> not they're paid for it. Hopefully we won't have to content with
> hundreds of students trying to get us to help them with their homework.
> 
> I'd like to try and put these thoughts into a coherent policy. Ideally,
> I'd like to get something down (even a rough draft) by the start of the
> fall term. If enough people think that I'm on the right track, it might
> make sense to start a wiki page to flesh some of this out.
> 
> Your thoughts and comments are appreciated (even a "that sounds
> basically right, Wayne" would be nice).
> 
> Wayne
> _______________________________________________
> soc-dev mailing list
> soc-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/soc-dev