Re: Advice for GSoC students

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.03.2012 12:11, Thorsten wrote:
> LRN <address@hidden> writes:
> 
>> As a former GSoC student, i can advice students to-be on certain 
>> aspects of the program. Where do i put that kind of information?
> 
> That would be really interesting!
> 
> I prepared some info pages for students 
> (http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-student.html),
>
>  I could offer to add your info on the student page, or make a new
> page for it, if you send it to me as a text file. Then, GNU could
> link to that page.
> 

Here's what i have to say on the topic (it's mostly freeform, so i
decided not to send it as a text file; if you do need a text-file
version, ask - i'll provide it):

Your chances to get accepted and complete GSoC successfully will
increase, if you're very good at software development. "Very good at"
usually means that you're top of your programming class, and you
probably dabbled in software development before becoming a student. If
you develop software on a regular basis, your skill will (usually)
raise over time, and your chances to complete GSoC will raise along
with it (that is, second-year students have more chances than
first-year students).
If you're a year away from your graduation and you've been the top
student in your programming class, and you're matching all other
requirements of a project, then (barring any unfortunate turns of
events) the probability of you being accepted and passing GSoC
successfully is nearly 100% (unless you're terminally lazy).
That said, if you aren't as skilled, but your experience with software
development has told you that you might have the right aptitude, then
you have a chance, never doubt that!

Obviously, look at the projects/organizations that use the programming
languages you know. You might not have a lot of experience using that
particular language; it's usually enough to just be familiar with it
(i.e. complete a course in C++ without writing any real C++ programs
other than those required to pass the course exams).
If you are not familiar with the programming language required to
apply for a project, but believe that you meet all other criteria (see
below), consider your learning ability, and try to read a tutorial or
a book that teaches the required programming language. If you know 2
or 3 different languages and know the right programming paradigm,
learning a new programming language is not very difficult.
If you are not an experienced programmer, and need to learn a language
for a project, then look for a project that requires the use of an
easy-to-learn language (Python, Ruby, etc). That will improve your
chances.
If learning is required, then do talk with the developers. Some
organizations have welcoming community and will gladly help you to
learn; others will not, and you will be left to your own devices.

Discuss an application with the developers. At length. Use IRC or a
mailing list - whatever is best for a given organization (some
organizations favor IRC, other - mailing lists). They might suggest
some ideas or variations not present in their ideas list.

You can also propose your own projects! If you've been dying to
implement a new feature in your favorite software package - here's
your chance! That is, if you find someone who will agree to be your
mentor for that project.

Fixing several long-sanding bugs might be considered important enough
to constitute a project. In fact, many pieces of software need
bugfixing more than new features, so don't be afraid to suggest
yourself for a role of Bugfixing Guru (that is, if you're sure of your
bugfixing abilities in the context of that particular organization).

Some (but not all) projects require not just programming skills, but
also some scientific or engineering knowledge (such as signal
processing, gene sequencing, law, artificial intelligence, and all
kinds of math). If you have the knowledge required for a project, and
are able to program at all (but not on the right language), then
that's probably better than knowing the required programming language,
but not having enough knowledge in the right field. But, again, not
all project require that kind of special knowledge.

Once you've chosen a promising project (or came up with an idea of
your own, and the developers from the organization you're aiming to
apply to think it to be a good idea, and you've found a mentor for
it), try to download and compile the source code for the software
you'll be working upon. If you need help compiling it - look for
tutorials/HOWTOs. Also ask the developers - they might have something
to say regarding your particular build environment and/or platform.
If you succeed - mention that in your application. It will score you
some additional points with the developers.

Once you've got things compiling, try to write something. If a [small]
subset or part of your project (one small feature, handling only some
of the simplest cases, and full of dirty hacks) can be completed
quickly enough (a couple of days) - try to do that. Otherwise, come up
with some schemes, or make a verbal descriptions of the changes you're
going to make, pointing out the places in the application's code that
will require changes, and how your code will interact with it.
If the project requires some kind of protocol or data storage - come
up with a protocol description or a storage format specification. If
the software you're going to develop is complex enough - make a
diagram or a flowchart that shows the components (existing and
yet-to-be-developed ones), and how they interact.
All of that will show the developers that you understand their code
and your task.

If the organization you're applying to has a wiki and allows you to
use it - do use it to publish some of the information for your
application. While Google will keep your application in Melange for
historical purposes, and it won't be lost afterwards, adding info to
organization's wiki page is already a small contribution and improves
your image.

Language skills are important. While this might not apply to all
communities, you'll usually get best results by participating in any
discussions (in chats and mailing lists) among the developers, if you
have something meaningful to say (but avoid "bikeshedding"). And you
should try your best to participate in any discussions related to your
project. With anyone, not just your mentor. If you're accepted, keep
your discussions public. Ask for advice, or for other developers'
opinion on things you do. Your mentor has some authority over you and
your project, but other developers might be able to help you better
(especially if your mentor is not available as often as you'd like
him/her to be), and their insights are valuable.
All that means knowing the right foreign language. If the developers
only speak English, and you don't, your chances to be accepted will be
lower (and if you're accepted, it might be more difficult to complete
the project). If one of the developers speaks the same language as you
do (happens in some large international organizations) - you might
pass, but again, this will hamper your ability to participate in
public discussions, which might reflect badly on your project.

Your ability to learn is important.
Good learning skills will allow you to quickly cover your lack of
knowledge or skill before and during the application period, and they
will help you complete the project once you're accepted. All software
developers learn, and you, as a student, will learn even more. Even if
you're an accomplished programmer, you still stand to learn a thing or
two.

If all of the above made you think that students who are well-prepared
and well-educated in programming, social interactions and sciences
have better chances of being accepted - you're absolutely right.
Luckily, such students are relatively rare. Don't be discouraged, even
if you're lacking in something - you'll learn as you go.

If you don't know English (or whatever language the developers are
using among themselves; but it's usually English) as good as you'd
like - take some time to write and proof-read your e-mails to the
mailing list, and try to participate in chats as best as you can. You
might notice that your command of English improves over time. Hey, in
many educational programs you have to pay to learn something. In GSoC
Google is paying YOU to learn! How cool is that?!

All things considered, it's better to do 2-3 good and well-researched
applications, than to apply for 10 projects simultaneously. Don't
spread yourself too thin.

Don't lie. Be objective.

Once you're accepted:

If you haven't done everything described above (code compiling, tools
familiarity, learning to participate in community discussions,
project-related research) - do that. There will be a stretch of time
called "Community Bonding Period" (about a month), it's purpose is for
you to get familiar with the code base, tools, documentation,
developers, etc (yes, that's right: while you're supposed to do some
of those things AFTER being accepted, doing them BEFORE being accepted
improves your chances to be accepted; sad, but true).

Google will require a copy of all your contributions at the end of the
program. Just a formality, but make it easy for yourself, and set up
some kind of version control system (or use the one the organization
of your choosing uses). Later you'll be able to dump all your changes
as patches, pack them and send that tarball to Google.

If you completed a 3-month project in 3 days, it means one of the
following:
A) You're a genius. The developers will find more work for your agile
mind.
B) Your project is too easy. The developers will find more work to
fill your spare time.
But that is a rare occurrence. Usually you'll be running out of time
instead. But it's OK to review your project during mid-term evaluation
and set new (realistic) goals, if the original ones can not be
achieved in time, and there are objective reasons for that. But it's
better to set realistic goals from the start, rather than change them
as you go.
Some projects allow for several stages of completeness. For example, a
project might include a major feature and a couple of minor features;
if you can't finish everything in time - concentrate on the major
feature, you might still pass the evaluation (obviously all that is to
be discussed with your mentor).

Don't take long breaks. The longer you stay out of the development,
the harder it becomes to dive back (although it depends on the nature
of the project and on your talents and personality; sometimes a
project is so interesting, that you can't wait to code some more!).

If you're coding for your project - think about your project. Thinking
helps too (sadly, it does not help you to pass the evaluation; a lot
of well-written and working code does).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPaHr7AAoJEOs4Jb6SI2Cw7roIAMoHsAiBPzdD+FS9hVXY7Nlb
dH9657L0ebeSPEeErcv0GiGUdSz8Mj1a8EjI+PiaTu7qXfTUfVVTV4+V5mcWtFIj
WYEYhVplQFfwdxrcHZsfCrc5iTKrmIxFolZXvUL/QfUFuuFKGE/qXyfRS5MBTd1I
5dO7bh1zlmvzDS8t9jrF2lcBYsI1d3gDP49ZpdqiHImRsqSXRYojBRBHMOsCsS17
0z9++hIjU594IQo3p6izVfIya+h2BqV6V+7aIWLv/JSYyWIcUNO3YyA2v0lNSIL6
tyr4PbEO8CHChAC1zAXkmI4+2yRNAQ54tRhiTRi705pgcjepfAPep0xJBbo8YVM=
=lGm5
-----END PGP SIGNATURE-----