-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dinesh Joshi wrote:
| This is NOT. I've seen this kind of "optional requirements" A LOT and | I have to totally disagree with them. By encouraging such "PLUSes" you | guys are NOT encouraging new entrants but rather encouraging the | already contributing members to earn a quick buck. I know its great to | have people contribute and when money is involved it becomes even | better. But by adding such PLUSes to your "requirements" applicants | who are willing to learn BUT dont have experience are thrown out and | downright discouraged. This is not the point of GSoC and the whole | reason it was started for.
I don't know whether you have read the recent blog post from pradeepto (http://pradeepto.livejournal.com/12565.html) but what he quotes from Till puts the bits into perspective. Yes, it is unfair for new contributors who don't have experience and perhaps in some ways it is not what the GSoC is about. But GSoC is not the average college / university project where some lecturer picks out a random bit from some IEEE or ACM paper and a bunch of students attempt to implement that without checking whether someone has already been-there and done-that (in the last 2 weeks, I have had a grand total of 30 such papers e-mailed to me by students who desire to do "projects" and in a year I get around 200 odd, including some applications talking about the same paper thus proving the college commonality).
However, having said that, the GSoC period is fairly well timeboxed and a rank newcomer (even if they are equipped with programming competence) would find it difficult to "get it". The "it" over here refers to the programming practices that are part of producing free and open source software (patches, code review, version control, IRC, mailing lists etc) as well as the entire architecture of the project to which contribution is offered.
Existing contributors who have code to show have a better chance of earning the trust of the mentor. Note, the mentor at a GSoC can be someone who just nudges the candidate in the proper direction and wrangles on his / her behalf with his upstream or, someone who does a deep dive into code. Either way, the mentor does not write code for the candidate and keeps up with his own contribution as well.
Applications where [i] the candidate does a random copy paste [ii] the candidate doesn't actually demonstrate that there has been thought behind the application [iii] the candidate uses templates and then is lazy enough not to erase details of the of the template cruft [iv] the candidate does not provide a draft timeline [v] the candidate contradicts him / herself within the application itself [vi] the candidate proposes a cosmetic change [vii] the candidate proposes a change that is not consistent with the project direction will end up having the odds stacked against them.
The mentors have a small time window to go through, review and score the applications and the process is sometimes more brutal than what Till mentions. A contributor who does not require too much hand holding is a contributor whom the mentor sees as most promising to deliver.
The harshness of GSoC selection is somewhat offset by GHOP and perhaps institutions would take it upon themselves to get some contributors to come down and undertake talks about "producing open source software".