Developers' side bar
<< | Page list | >>
Template for LyX Summer of Code 2013 Students' applications
Summer of Code 2013 - Application Pointers
A proposal should contain two parts: (1) An introduction, and (2) a project plan.
In the introduction, describe where you come from (among other things, it is good to know which time zone you are in), and your background (programming tools you know, projects you have participated in). Be brief; we are looking at many proposals so a list of your hobbies and favorite movies is not of primary interest to us. However, it is a good idea to include a motivation for your proposal. As a user, have you run into the particular problem that your GSoC project is going to solve? That is a very good way of getting a clear vision for the project plan.
Finally, it is always a challenge for us to judge your programming skills. Therefore, if you have anything to show that you can write good code in LyX or a similar environment, please highlight that. This may be in form of a previous project, or contributions to other projects.
Part 2, the project plan, is the key part of your proposal. Your plan should contain a clear goal, and a path to reach it, divided into subgoals. Having subgoals also allows us to adjust the schedule in case things do not go as planned.
In particular, if you have other time commitments (such as exams), make sure to let us know and adjust your plan accordingly!
As you can see from Google's web site, the key dates are:
June 17: Begin coding
July 29: Mid-term evaluations
Sept. 16: "Pencils down" with a one-week grace period.
This means that the main work periods are six and six + one weeks. Based on this, we recommend that the main goal (for the overall project) has a mid-term milestone, and there are two more subgoals in the middle of the first and second phase, respectively.
It is often the case that at the beginning, unexpected problems occur. It is therefore important that you resolve any configuration/compiler issues during the "community bonding period" before June 17, so at least these problems will be out of the way. You can even try simple changes before that date, to ensure you can work productively without having to ask for advice immediately (as mentors may be in different time zones).
We recommend having the first subgoal consist of a set of simple "warm-up" tasks, so you can get familiar with the project and have some early success.
Based on this, a possible schedule looks as follows:
June 17: Begin coding
July 8: First subgoal (for example, a number of examples and tests, and a proof of concept).
July 29: Mid-term milestone. The basic functionality of the summer project should be established, but maybe only for simple cases or without additional features.
August 19: Second subgoal (getting enhancements towards the main goal done).
Sept. 16: Final goal.
The three-week rhythm lends itself well to agile development. This means that you should test the code as much as possible throughout the project, and maintain high code quality (including drafts of the documentation) as well. This way, you avoid running into problems towards the end of the project. We recommend leaving the final week for final debugging, and finishing the documentation (which should already be in draft form then.) Don't be overly ambitious; we are looking for code that we can keep and maintain in the future, so one feature less may be better if quality may otherwise suffer.
The first subgoal should already be very clear in the proposal, such that you can describe it in more detail. The "requirements" and design in your proposal can also be used later to document your project.
Again, if you have schedule constraints, we can accommodate for them by adjusting the scope of a project. However, please let us know beforehand, as it is difficult to adapt in the middle of the project.
Finally, while we understand that English is not the first language for most of us, please be diligent when writing your proposal. Spell check it, and use proper grammar and punctuation.
Summer of Code 2013 - Student Application Template
In your application let us know your:
You should provide all the information listed above, but we are not looking for a simple list.
Sell yourself! Get across your enthusiasm for the project. Tell us what makes you stand out from the rest of the crowd. Talk about your past experiences, what makes you tick. Why are you interested in open source software, and Lyx in particular? What interests do you have, and how do these interests relate to the project for which you're applying? There is a basic assumption that people applying for Summer of Code will have at least some programming skills already. So rather than spend a lot of time elaborating on these (though by all means, do tell us what you know), spend time talking about you.
In your application let us know
It is very important you discuss your idea with some established LyX developers. If your idea duplicates existing efforts or code (and does not provide a very convincing reason for doing so), it will be rejected. Try to have your application reviewed by someone before you submit it, whether that be the mentor for a particular project itself (in the case of already generated ideas on the ideas page), or a person with expertise in a certain area (such as (La)TeX, QT, XHTML, etc.) Don't be afraid to ask us on the developers mailing list or by writing in private to the admins. We want you to succeed just as much as you do!