Re: [soc-dev] Generalizing SOC

["Remy Chi Jian Suen" <remy.suen@xxxxxxxxx>]

I think this is a good direction and we should take this to the wiki.

I like the bit about not associating a timestamp (since that
potentially has some negative implications and is unwieldy) and the
"Proposal" component bit where people can have an open discussion
about a potential project kind of like what's done for Eclipse.org
articles.

Regards,
Rem

On 8/15/07, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
> 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
>