Abhilash Raj writes:
> 1) I need to discuss about the design of the idea that I want to
> implement. I know the rough bits but need help and comments on
> what I proposed. This would require views from the whole
This is place for that, not private consultation with the mentor.
Just start spelling out your ideas, and post them here for comment as
they're developed to the point you can get useful comment. And don't
worry about whether you are doing it right: just do it. Sooner is better.
One reason for this approach is that as Google sees GSoC, one purpose
is encouraging the student to develop his or her relationship with the
community. The best case is somebody who enters with several months
of presence on the developer lists (but that is in no way required,
it's more an "it would be nice if" example).
We actually would like have the proposals posted here, but
unfortunately that tends to interfere with evaluation for several
reasons. (One important one is that often several students propose
similar projects, and if the proposals are public there's a very
natural tendency for them to converge, making selection nearly
impossible.) Now that we have the proposals in full, we'd like you to
start engaging the community by posting your ideas, designs, and
It's probably best *not* to post big chunks of your proposal. Maybe
the "short description" as an introduction, but after that you should
pick a particular task and get the community to help you start on it.
> 2) Apart from the corner cases mentioned in the proposal there might be
> many other not caught in my eye. I would need them to be pointed out so
> that a solution of it can discussed and then implemented.
> 3) There is a lot of cryptography in this project, so I would need a more
> experienced view to find and remove the security loopholes.
These are more specific to your topic, but they are also best done on
this list, especially the issues related to security. The advantage
of the mentor system is that you have somebody who has to look at your
stuff. Still, the best way is to get comments from a broad selection
of developers and users.
> 4) Lastly since I am still a noob in programming I would need regular
> review on the code for the first 2-3 weeks so that I cam improve
> and write bug free production code.
Well, the first thing to learn is that nobody writes bug-free code.
Anticipate that your code is going to be buggy, catch as many as you
can systematically (I recommend Watts Humphrey's book "Introduction to
the Personal Software Process", I'm sure other mentors have their
favorites). Then get reviews from others (including but not limited
to your mentor(s)).
Once again, what we are looking for (Richard posted as representative
of the mentor team) is discussion of your plans: the pieces of the
design puzzle, of course, but also your motivation for proposing the
project, and your plans for advancing it.
I emphasize what Richard has already mentioned: this is not a test
where you have to do everything yourself to get points.
You will be evaluated on the functionality you present to us at the
midterm and final evaluations, not on whether you wrote all the code
yourself. Some of the code you can borrow from existing modules, and
some you can beg from others. Your mentors are going to be working on
their own projects, and schedules can be adjusted to provide pieces of
the puzzle you need sooner rather than later. Other experienced
developers may be willing to help out. In some cases you can get
parts of what you need from other students in GSoC (but this requires
delicate negotiation and careful management by the mentors involved;
we'll cross that bridge if we come to it).
The rest of the code you have to write, and there's a minimum (a
substantial size, at that) we'll be expecting. But the more code you
can get from elsewhere, the better the product you'll produce this
 The others, of course, are financial support for a student
getting practical experience in software development, concentrating on
coding, and development of worthwhile software for the mentoring org.