On Mon, 2014-09-15 at 09:08 +0200, Christophe Fergeau wrote:
Hey Michael, On Sun, Sep 14, 2014 at 07:15:42PM -0500, Michael Catanzaro wrote:It would also be good to actually consider the value of student projects before funding them. With GSoC we just picked which students seemed most likely to successfully complete the projects they proposed, rather than actually evaluating which projects were most important to GNOME.Most of the GSoC projects we get proposals for are ideas which were suggested by mentors/members of the GNOME projects on https://wiki.gnome.org/Outreach/SummerOfCode/2014/Ideas Students are also encouraged to come up with their own project ideas, but in this case we insist that this must be discussed with the project maintainers first to make sure that this is something that is useful to the project. Then there are indeed some (a few!) more experimental projects that we pick because the student seems good, and this could have an interesting outcome, but we don't pick a lot of such projects each year.
Yes, but I don't think that process is sufficient. Some of the projects that get accepted seem to be of significantly higher value to GNOME than others. Others are important, but not really enough to merit the entire stipend.
I think we got a good set of students, but I'd rather select a promising student while rejecting the student's project proposal if the proposal is only tangential to our interests.You seem to imply we should reorient good students on more important projects if what they propose does not seem very useful?
Yes! Within reason; we don't want to push students to work on projects they're not interested in, but we also don't want to fund them to work on something that's largely tangential to our interests.
One thing to keep in mind about GSoC is that we don't know in advance whether the student will manage to complete their project during summer or not. This means it's generally preferrable not to push students to work on features which _must_ be in the next GNOME release, as we may then realize very close to code freeze that this very important feature is not going to be completed by the student in time for the release.
I agree. It's better for GSoC/OPW projects to focus on achieving a non-urgent goal. This is already the case for all, or almost all, of our projects, though.
Attachment:
signature.asc
Description: This is a digitally signed message part