[Soc-coordination] Possible GSoC idea: (Near) real-time updates of (UDD) bug view

[Lucas Nussbaum]

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