Tips to GSOC students

[Mojca Miklavec]

Dear GSOC candidates (and future MacPorters :),

(Sorry for the slightly longer email.)

I would like to thank each and everyone of you for reaching to us in
the hope to have a wonderful summer together, hopefully with a great
learning experience and contributing something awesome to our project,
potentially making a huge impact on all our users.

There are only three weeks left until the final deadline for
proposals. This is the deadline you **may not** miss in order to be
eligible for the program. However one week from now is the deadline
you **don't want to** miss if you want to increase you chances to get
selected.

I would strongly encourage all students to submit their draft proposal
as soon as Google starts accepting them (or even earlier and send us a
link), on March 25th. Keep in mind that this is still a draft: it
doesn't need to be perfect on day one, but be prepared to work hard to
improve it to perfection before the official deadline (9th April) is
reached. Aim to have it finalized a few days before, just in case. If
you don't show us your draft early, we cannot provide feedback about
how to improve it.

Tips:

(0) Be available all summer

Does your university requires from you to complete a compulsory
internship this summer? Please ask them if you can make GSOC count as
internship. If they don't allow you to do that and if you cannot avoid
going on internship during the GSOC period, please spare the troubles
to both you, your potential mentors, your company ... and don't apply
to GSOC this year, you'll likely have another chance next year. You
cannot do both full-time internship AND full-time gsoc coding at the
same time. If you take the spot and don't complete the project, you
don't get any money. but you take away someone else's stipend.

That said, please let us know your university schedule (start and stop
of lectures / exam period) and potential shorter vacation days, just
to be able to plan better.

(1) Plan to deploy your results before the first evaluation

Create a clear timeline with clearly defined milestones. Ideally an
important and standalone subset of your project should be deployed
(documented, with test cases etc.) before the first evaluation period.
This will then give you enough time to get feedback from users, fix
all the issues that will arise while testing, improve the project
according to feedback (something you probably didn't even plan
initially), in case of statistics project actually be able to collect
some data early enough to see what needs improvements ... Of course
you would continue with active development for the whole summer, it's
just that we don't want yet another project to end up at 70% by the
end of the summer and then never get deployed (or, even if deployed at
the end, never get a chance to fix the most burning problems).

(2) Dream

Add a section of all the things that might not necessarily be achieved
in the given timeframe, but which you would like to add if you finish
with the core application early, or things you would like to see
implemented after GSOC is over. (Extension goals.)

(3) Prove your skills

Make sure that you show us your ability to solve the kind of
challenges that you would be working with during the summer, either by
some demo or by contributing some pull requests or other patches. If
you still need guidance, let us know.




Below is a special section devoted to interest in the same project.

We try our best to keep the full process open and ask the students to
communicate on the mailing lists rather than privately, unless it's a
private matter or a one-to-one skype meeting / briefing.

This year we seem to have multiple students interested in a single
idea (web app for build & installation statistics), so I want to share
some of my personal views (mixed with somewhat official guidelines,
but most of them are not official). In case that more than one student
apply for same project, there are the following possible outcomes:
- none of the students gets selected anyway (none reach the high
standards, or another proposal is a lot better and we run out of
slots)
- only one proposal is good enough and gets selected
- two proposals are excellent, but we can only pick one student (the
second one with still excellent proposal has bad luck)
- we get two excellent proposals for the same project, but at least
one student also submitted the second proposal for an alternative
project, which might allow us to select both

We cannot have more than one student work on the exact same project,
since we don't want to end up with two solutions, out of which one
would be thrown away, as that's waste of both our and student's
resources. We should also not let the work of two students be too
dependent on each other. Let's say that one student drops out: the
second student should not fail (being unable to complete the project)
just because the first one did not perform. We should also not end up
in situation where one student fears to submit a proposal for the
project he or she is most passionate about, and instead submit a
proposal of a much lower quality for something else.

There is enough work for multiple people for the web app project as
well, it just that these boundary conditions make it a somewhat
complicated situation. Please note that my email is not implying any
of those four options mentioned above. I haven't seen any proposal
yet, so we cannot even judge anything yet, and we don't know how many
slots google will assign to us either.

My **personal** suggestion would be that any student should submit a
brilliant proposal for the idea that he's most passionate about.
Include a longer section with extension goals. Then, explore and
include also plan B if you feel that someone else might be in the game
for the same project.

You may keep in mind that the exact project might still change
somewhat after the application period is over, provided that both
mentor and student agree, so the exact content is not yet set in
stone.

A project with buildbot improvements is relatively tightly related to
build & installation statistics where I can easily imagine one month
of independent work, followed by some synergies to integrate stuff
together.
An alternative way is to start exploring macports base.

If something is unclear, feel free to ask.

Mojca

(I explicitly CCed those who recently contacted us, but the same
message should go to any student who might contact us later.)