How to write applications for KDE Google Summer Of Code?

Mar 18, 2008 13:01

I posted this. And Till Adam replied with the following ( please read it *CAREFULLY* if you are planning to participate in GSoC and KDE GSoC in particular ) -

> There is a nice *idea* page on the KDE techbase page [2]. Feel
> free to browse through that and find something that you like or you
> might be able to pull off. *Strong recommendation* - Please be
> creative and write your own project proposal. Nothing impresses
> mentors more than your own enthusiasm to do something uber cool for
> the project. It is million times better if you write your own project
> proposal - may be even your own idea that is not there in the idea
> page which you think might be a cool feature / addition to KDE -
> instead of copying something from the idea page.

As someone who will get to read and rate the applications again, this year,
I'd like to strongly second that. Obviously copy-and-pasted applications get
an immediate massive markdown, at least from me. We have hundreds of
applications to read and review, I won't waste time on people who don't even
take the time to write up what they want to do themselves, even if the idea is
from the ideas page.

The following are the questions I ask myself while rating proposals, and I
know that many of the other mentors have similar frames of reference:

- is the idea directly relevant to KDE, if not -> suggest a better mentoring
organisation and throw it out. Many proposals are submitted in several places,
often KDE is not the right one

- is the proposed project non-trivial and requires more than painting by
numbers? GSoC is not supposed to pay people for a busywork summer job, but for
creative, challenging work

- does the application sound like he/she knows what the hell they are talking
about? It's ok to be unsure about stuff, and say so, but being blatantly wrong
and ignorant of basic facts doesn't help, nor does pretending to be super-
experienced and knowledgeable.

- is the project doable at all? "I shall find a cure for cancer. if I have
time, I will also cure HIV." -> gone

- does the applicant have the necessary technical skills to accomplish what
they propose in the timeframe? "First I will learn C++, then I will learn Qt,
then I will learn KDE programming, then I will write KCureCancer." -> gone.
Starting completely from scratch just isn't possible in the time frame.

- is there a clear plan and/or roadmap detailing what the project entails?
"First I'll need to do this, then investigate if this or this is better, then
ask this person for help with that over there, then evaluate this technology,
then implement this, and this and this." -> good. Rough time estimates are a
plus too, they shouldn't be off by two orders of magnitude, though. "Then I'll
need a day or two to rewrite kiosk framework" -> gone

- does the applicant have the necessary communication and other soft skills to
work succesfully with their mentors? This is a judgement call based on how the
proposal is written. We'll also often ask questions, during review, in the
comments, which the applicant can answer. If those answers are very terse or
they don't get what we are asking -> gone

- is the proposed project interesting and do I see it benefiting KDE and being
integrated? This is subjective, of course. It can trump everything else,
though, for me personally. I'v emarked up one-paragraph proposals solely
because they were truely interesting ideas.

- does the applicant seem passionate and genuinely interested in what they
want to work on. "I had a brief look at GNU Contact, and it seems nice enough,
although I personally use Outlook, mostly." -> gone

- are they willing to learn and be mentored? Again, judgement call, but it's
often pretty clear while reading an application that if I were to tell the
person "No, you are wrong there", they would come back with "You don't have a
clue, sod off, I'll do it my way anyhow." Not helpful, obviously.

- have they put considerable effort into the application overall? does it seem
well researched, thought out, revised, shown to friends, revised again,
worried over, etc., or does it look like it was thrown together in half an
hour to see if maybe it gets in. This includes stuff like formatting, language,
spelling, etc. Treat it like a job application. Seriously, in other words.

I realise that this seems harsh, and that many of the criteria are not
objective and reflect my personal biases (and obsession with spelling ;), but
given the avalanche of applications we have to process, one has to find ways of
getting rid of most of the crap ones quickly so that there is time to
appreciate the good ones in more depth. If you get a question from one of the
reviewers, that means you've survived the first round of screening and your
application might have a chance, so by all means answer the damn question, and
take sufficient time to do it. Failure to do that has killed many a decent
application unnessecarily.

If you have any further questions, I'd be happy to answer them. I will not
write your applications for you, though ;)

That said, I would love to see a strong showing from India this year, got to
beat last year's record of three, right? So get cracking, free Indians,

Till

I am sure that helped a lot. Now writing the application and pursuing it further will be clearer and easier. Thanks Till. And yes, would be great if we can beat last year's record of 3 :). Do take some time and read up on last year's applications, talk to last year candidates to find out what they did right and how they did it :). Good luck!

google summer of code, kde, application, gsoc

Previous post Next post
Up