Before we get to the actual application form, some important remarks about the
application process -- please read them carefully.

First of all, please give your application a useful title. In many cases, you
can simply copy it from the project ideas list. Some ideas -- like language
bindings for example -- are rather broad, and require an additional specifier.
(e.g. "Python Bindings")

If you are proposing a project not on the ideas list, you have to find a useful
title yourself of course -- but surely this isn't hard, if you were able to
come up with your own project idea

Submitting the application form is only part of the deal: we expect a few other
things on top of that, as explained below. This is important, so please take
it seriously -- without these things, the application is not complete, and we
won't consider it.

One of the things we expect is that you contact us directly as soon as possible
(preferably even before you send the application form), on our developer
mailing lists and IRC channel. Don't be afraid -- we won't bite IRC
in particular allows for very informal conversations.

(Note though that we are not all in the same time zone, and people generally
don't stare at the IRC screen all the time: it can take quite a long time
until somebody replies -- even several hours. Don't get discouraged by that. Just
be patient and hang on, or try again later.)

Contacting us as soon as possible is crucial, as regular communication is the
single most important factor for a successful GSoC project. We need to see that
you are able and willing to talk to us regularly. Also, we get to
know you much better this way than what the application form alone would allow us to.

You shouldn't be at a loss for reasons to contact us. You ought to discuss your
project and application with us for example -- you will gain a much better idea
about the project, our expectations etc. In short, you will be able to
submit a better application right from the beginning, saving both yourself and
us some tedious round trips

Also, if you really want to get involved with the Hurd project, there are
surely many things you will want to know -- after all, it's a fascinating
project, with a fascinating architecture etc., right?

All in all, you should have ample
causes to get in touch during the application period. Bonus points if you also
participate in discussions not directly related to your project.

The other thing necessary to complete your application is making a change to
some part of the Hurd code, and submitting a patch implementing that change. (If you are
not sure what that means, ask us!)

This is important, as it shows that you have everything set up to start hacking
on the project (source code, tool chain, testing environment etc.); and that
you have all kinds of qualifications necessary to successfully finish your
project: general programming skills; working in the Hurd environment;
submitting patches and reacting to feedback; finding and/or asking for any
information you need; and so on.

Don't get us wrong: We absolutely do not demand that you have and know all
this up front. After all, the idea of GSoC is to introduce you to free
software development in general, and to our project specifically We are
eager to help you with anything you will need to create the patch -- you just
need to ask!

We actively encourage you to contact us whenever you have any doubts. Don't be
afraid that we will think worse of you when you ask too much. On the contrary:
this is an occasion for you to show us that whenever there is something you
don't know yet, you are able to learn quickly, and know how to ask for help

As for the kind of change we want: ideally, it would be some real improvement
(bug fix or new feature) in a part of the Hurd related to the specific project
you want to work on. (This is not always possible though -- in that case, a
useful change to some unrelated part of the Hurd would also do, or perhaps some
not strictly useful change to the part you will be working on.)

The project ideas page has more information on this. In either case, please
contact us, so we can discuss it, and together come up with something suitable.

Note that we do not place any demands on the size of the change. Even a very
simple modification suffices to meet the minimum requirements -- after all, the
amount of time available for working on this before the end of the student
selection process is quite short; and you are not obliged to do a substantial
amount of work before you get accepted. (But if you feel more ambitious, that's
fine of course )

Now to the actual questions in the application form. Please answer all
questions -- we are asking them for a reason. (Whether you answer them one by
one, or all in a larger piece of prose, is up to you.)

If some of these questions look strange to you and/or you don't quite know what
to answer, don't despair. This is not some kind of exam -- we do not expect you
to have good answers for all of them up front. (In fact, we would be very
surprised if anyone did...) The idea is more that you learn the answers before
the end of the application process -- with our help. Please talk to us whenever
you are unsure about something.

Introduce yourself: who are you, where are you from, what do you do, how did
you get here... Don't write a long essay here -- just a bunch of basic facts
you think we should know, so we get some idea whom we are talking to

Please describe the task of the project you want to work on, in your own
words. Be as specific as possible. It's not sufficient to rephrase the
description from the project ideas page -- show us that you actually understand
what this task involves! Read the available documentation (and possibly code)
if necessary. And don't hesitate to ask us if you have any doubts

Give a preliminary schedule for your work. The exact dates will obviously be
only guesses; but try to be specific about all the individual steps you will
have to do to complete the task.

Note: By the end of the summer session, the code is expected to be in a state
ready to be merged to mainline. Experience shows that adding the "final
touches" necessary for that, tends to take up quite a lot of time -- there are
always some bugs here and there, some misunderstandings about how things are
supposed to work, build system issues, missing documentation, forgotten bits,
and so on. Thus, the schedule should assume that a larger part of the main
implementation work will be done by midterm!

Also note that by the beginning of the summer session, you need to be able to
work on the task at more or less full speed -- meaning that you need to get
familiar with the code, think through the design (and discuss it with us) etc.
already in the interim period before the summer session.

What things will you have to learn to be able to complete the project? What
do you already know?

In case you wonder what this question is getting at: Again, we want you to show
us that you really understand what kind of work the task involves. As always,
we encourage you to ask us for pointers if you are not sure how to go about
this

Why did you choose this project idea? What do you consider most appealing
about it?

Please describe your previous programming experience in detail. What
languages do you use? How long have you been programming, and how much? What
kind of programs have you written? What kind of programming (and related) work
are you enjoying most?

Have you been involved in any free software ("Open Source") projects yet?
Which projects, how long, and in what way have you been involved? Have you been
active in the Hurd project/Hurd community before?

Please briefly describe the Hurd, including the goals, architecture etc.
Also, what makes you interested in the Hurd? Why do you want to work on it?
What is your vision of it's future development?

We ask this because we want to make sure that people working on the Hurd do
understand what it is all about. You will probably need to read some
documentation -- as always, you are encouraged to ask for pointers, and
generally to talk to us about it

Are you subscribed to the bug-hurd@gnu.org mailing list? (See
http://lists.gnu.org/mailman/listinfo/bug-hurd )

Hint: This is mostly a rhetoric question. If you haven't subscribed yet, now
would be a good time to do it! You will need it to communicate with us during
the application process.

Do you have a permanent internet connection, especially during the time of
the summer session? Are you able and willing to hang out on the Hurd IRC
channel regularly? (As in: Running the IRC client more or less permanently and
checking for activity now and then.) If it turns out that your mentor lives in
a different time zone, could you shift your day/night rhythm to better match
that of your mentor and other Hurd developers?

Hint: Hanging out on the channel regularly during the application process
would be a good start

When does your university term end, when are your exams, and when does the
next term begin?

We need to know up front whether there are any overlaps with the GSoC time
frame (especially the summer session), so we can make a plan how to deal with
it properly.

How much time do you intend to spend on your GSoC project per day/week during
the summer months?

Note that according to the GSoC FAQ, the project is meant to be "your major
occupation during the summer". In other words, you should treat it more or less
as a normal full-time job.

What other major activities will you engage in during the summer? (Moving
apartments, longer vacations, other obligations, etc.) If any, how do you
intend to make sure you will be able to dedicate sufficient time to your
project nevertheless?

Please be open about this, and also mention things you are not yet sure about.
We can be flexible about time arrangements; but we absolutely need to know about any
possible obstacles up front. Surprises on that score are not acceptable.

How do you intend to make sure that your code will keep on being maintained
and supported properly after the end of the GSoC program?

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
GNU Free Documentation License.