| Re: [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