On 07/03/13 at 19:07 +0100, Stefano Zacchiroli wrote: > On Thu, Mar 07, 2013 at 10:06:06AM +0100, Lucas Nussbaum wrote: > > My plan would be to monitor BTS and archive changes using e.g. inotify. > > That would be part of a rewrite of the core of UDD. I'm not very much > > motivated about mentoring a student on that, unless it's a very good > > student. (I plan to work on that myself at some point) > > So, other projects, most notably those who tend to get *a lot* of > applications due to their popularity as proper software development > projects, have best practices for these cases. For instance, one is to > have some simple "test" that students should pass and include the result > of their work as part of the application; if they don't, or if the > result is poor, they get ranked very low. > > An example I'm familiar with is, for a FOSS project that has some kind > of UI with an about dialog, "include in your application a patch that > add your name somewhere in the about dialog". This is very simple to do, > but shows that the students have the minimum skill to find the code, > install all its build requirements, do the build, produce a minimal > patch, etc. This is a general practice we might consider to reduce both > evaluation load and the risk of being disappointed later on. > > More to your case, I fully understand having high expectations before > being willing to mentor a student. So, how about devising a small > exercise, which somehow measures the minimum skills you expect to be > willing to mentor? It might seem draconian, but after all we do not > want to *force* anyone to mentor students they're not happy with. Some > exercise like the above might be a compromise.
I'll think about it (before the 18th) :) Lucas _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
