On 03/17/2014 08:31 AM, Junio C Hamano wrote: > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > >> Perhaps it is time to mark this microproject as "taken" on the GSoC >> page [2], along a fews others for which we have received multiple >> submissions. I just marked #8 as taken, as it's been beaten to death. I haven't been keeping careful track of which other microprojects have been overused. If you have suggestions for the chopping block, let me know. >> [2]: https://github.com/git/git.github.io/blob/master/SoC-2014-Microprojects.md > > I actually have been of multiple minds on this. > > * After seeing that many candidates tried to solve the same micro, > apparently without checking answers by other people, and seeing > how they responded to the reviews given to them, I found that we > had as equally good interactions with them to judge their skills, > both techincal and social, as we would have had if each of them > solved different micros. > > * Many reviewers may have gotten tired of seeing many novice > attempts on the same micro over and over again, giving gentle > suggestions for improvements. Because the _sole_ purpose of these > micros were to help candidates get their toes wet in the process, > duplicated efforts on the candidates' side are not wasted---they > each hopefully learned how to interact with this community. > > But it is true that, if we were wishing to also get some trivial > clean-ups in the codebase as a side effect of these micros, we > have wasted reviewer bandwidth by not having enough micros, and > reviewers may have had some feeling that their efforts did not > fully contribute to improving our codebase, which may have been > discouraging. > > Big thanks go to all reviewers who participated despite this. If > we had more micros, the apparent wastage of the reviewer efforts > might have been avoided. > > * Many candidates did not even bother to check if others are > working on the same micro, however, which would be a bad sign by > itself. Concentrating on one's own topic, without paying any > attention to what others are working on the same software, is > never a good discipline. > > Some may argue that it would be unfair to blame the candidates on > this---they may have picked up micros that haven't been solved if > we had more---but after seeing that many candidates' submissions > apparently did not take into account the reviews given to others' > submissions on the same micro and/or had many exactly the same > issues like log message styles as submissions on other micros > that have already been reviewed, I personally do not think they > are blameless. > > 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. I also hope that students didn't feel unwelcomed during the times when the list of untaken microprojects was nearly empty. 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. Maybe students would have to claim a microproject when they started work on them, or request a microproject to work on as opposed to picking one from a list on a web page. But realistically, I think that this hypothetical improved system would be more work than we would have been able to invest. Maybe in the future our microprojects should have two parts: a. Fix ... b. Invent a microproject for the next student. (Just kidding.) > Again, Big Thanks to Michael for the excellent "micro" idea, and all > reviewers who participated. I'd really like to thank the reviewers, who put in enormous effort reviewing submissions promptly, and showed superhuman patience when dealing with the same issues over an over again. Without such great reviewers the whole idea would have just resulted in frustration for the students; with them, I think that even the students who don't get a GSoC spot will have learned something valuable from their participation. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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