Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 03/17/2014 08:31 AM, Junio C Hamano wrote: > >> So in short, yes it would have been nicer if we had more micros than >> candidates, but I do not think it was detrimental for the purpose of >> these micro exercises that multiple candidates ended up attempting >> the same micro. > > I wish I had had time to invent more microprojects. I think we were > lucky: since students didn't seem to learn from each other's attempts, > the fact that many people tried the same microprojects wasn't much of a > problem. But if a student had arrived with a "perfect" solution to a > well-trodden microproject on his/her first attempt, I would hate to have > to be suspicious that the student plagiarized from somebody else's > answer plus all of the review comments about the earlier answer, > especially since a perfect solution would itself reduce the amount of > interaction between the cheating student and the mailing list compared > to a student who required several iterations. It may probably be not a huge problem. If anything, a cheater would have also learned how the mailing interaction goes when trying to plagiarise. And not really having interacted us, a cheater would have left us no impression on his or her communication skills, so it would probably have been detrimental for his or her own chance to be chosen as a student, compared to the ones who started from their own solution and polished it by responding to reviews. > I also hope that students > didn't feel unwelcomed during the times when the list of untaken > microprojects was nearly empty. Yeah, that is why I said I was of multiple minds. I wasn't enthused by seeing the ones that somebody is attempting marked as "taken" in the first place. Solving one that others attempted in his or her own way and interacting with reviewers seemed to have just as much information on the candidate, at least to me. > If we really wanted to make this system cheat-proof, there would have to > be not only enough microprojects to go around, but also some mechanism > to ensure that student B didn't start work on a microproject that > student A was just about to submit a solution to. Nah, I do not think there is any need to go there. It is over for this year anyway, but I do not think such a provision is necessary for future years, if Git project will participate in future GSoCs; see above. > Maybe in the future our microprojects should have two parts: > > a. Fix ... > b. Invent a microproject for the next student. > > (Just kidding.) ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html