Hi Isabel, While gitHub is certainly an easy way to manage this kind of thing, if you want easy integration with the Mahout community, I could imagine that making a separate SVN branch for them, and then your students could have mentors (like GSoC) who would review their code and commit to that branch (and committing to that branch could be done with less stress and worry about destabilization than to trunk, and thus would not require as much time/energy/effort/big monster patches).
The community could easily monitor what's going on in that branch, and periodically new branches from trunk could be cut which this TUWoC branch could periodically merge onto (to keep from diverging too far from trunk, and provide periodic "tests" to see if the merge would not destabilize trunk). Then at the end of TUWoC, a careful review of what was to be merged down to trunk could be done, and some subset of that branch could make it all the way to the trunk. Just one possibility. -jake On Fri, Oct 2, 2009 at 9:02 AM, Isabel Drost <isa...@apache.org> wrote: > > Hello, > > as explained some weeks ago, I am planning to do a Mahout course at TU > Berlin that involves a theoretical seminar as well as a coding project. > > I imagine a setup where small groups students are working on tasks > - comparable to the GSoC setup* - implementing features end-to-end > (including tests, javadoc, documentation, examples etc.) I cannot > guarantee for anything but ideally I would wish for the results to get > back into Mahout. > > I would like to avoid submission of "monster-patches" and get students > to learn to interact with version control (git, svn...). Obviously we > cannot give each student commit access. On the other hand I do not want > to take development out of Mahout to some github project - would work > but than the Mahout community would not be able to monitor progress. Is > there any way for those students to work in some sort of sandbox area? > Any other suggestions? Could github be a viable way to go with patches > being broken into reasonably small pieces and submitted to JIRA? > > > Isabel > > > > * Of course there will be no money involved. But community interaction, > reviewing patches, fixing bugs from JIRA and code quality will be taken > into account when computing the credits students get. >
