Projects/Summer of Code/2007/Participation

All students and developers are welcome to participate in the Summer of Code program, with KDE. Here are the instructions on how to participate.

Instructions common to all participants

All participants should take a look at the Summer of Code Program Wiki every now and then to be informed about updates and advices. It is also important to read the Summer of Code FAQ, as it contains useful information.

All participants will need a Google account in order to join the program. You'll save some time if you create one now.

Timeline

For the 2007 edition of Summer of Code, the program timeline is as follows:
(extracted from the official timeline - refer there for updates and more information)

• March 12: Mentoring organization application deadline
• March 14: List of accepted mentoring organizations published on code.google.com;
  student application period opens
• March 24: Student application deadline

• Interim Period: Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant

• April 9: List of accepted student applications published on code.google.com

• May 28: Students begin coding for their GSoC projects; Google begins issuing initial student payments
• July 9: Students upload code to code.google.com/hosting; mentors begin mid-term evaluations

• July 16: Mid-term evaluation deadline; Google begins issuing mid-term student payments
• August 20: Students upload code to code.google.com/hosting; mentors begin final evaluations; students begin final program evaluations

• August 31: Final evaluation deadline; Google begins issuing student and mentoring organization payments

Licensing

Code for Summer of Code projects must respect the general KDE Licensing Policy. Special circumstances may require exceptions, but they should be cleared with a KDE mentor or maintainer.

The only restriction that Google places is that the license be one of the Open Source Initiative approved licenses.

Language

While the main KDE development occurs in C++, we do have bindings for many other languages, including (but not limited to) Python, Ruby and C#. Some bindings are more stable and more mature than others. Some may not be suitable yet for serious development -- be sure to take that into account before making your choice.

C++ will be accepted for any project. Submissions and ideas for projects in any other language should specifically mention the choice.

KDE 3 or KDE 4?

In 2006, we accepted projects for both platforms. For 2007, we'd like to see more focus on the upcoming KDE 4 platform, but we will not reject nice ideas for KDE 3-platform applications.

Note, however, that KDE 3 itself is now frozen: no major development is occurring in it. A project aiming at improving a KDE 3 application may be received with little interest (but won't be excluded right away). Such a project should preferably indicate how the KDE 3 code will be migrated to the new platform.

Instructions for students

Students wishing to participate in Summer of Code must realise this is more than a mere formality. You will be required to produce code for KDE in 3 months (see Timeline for more information). You will also take some resources from KDE developers, who will dedicate a portion of their time to mentoring you. Therefore, we'd like to have candidates who are committed to helping KDE.

You don't have to be a proven developer -- in fact, this whole program is meant to facilitate joining the KDE and other Open Source communities. However, experience in coding and/or experience with KDE/Qt libraries and applications is welcome. If you can, start familiarising yourself with the components that you plan on working on before the start date. KDE developers are available on mailing lists and on IRC for help.

General instructions

First of all, please read the instructions common to all participants and the Summer of Code FAQ. Pay special attention to the Eligibility section of the FAQ.

Recommended steps

1. Read the instructions for participating
2. Take a look at the list of ideas
3. Come up with project that you're interested in
4. Write a first draft proposal and get someone to review it for you
5. Submit it using the web interface (not available yet)

Coming up with an interesting idea is probably the most difficult part of all. It should be something interesting for KDE, for Open Source in general and the Linux/Unix desktop in particular and for you. And it also has to be something that you can realistically achieve in the time available to you.

Finding out what the most pressing issues are in the projects you're interested in is a good start. You can optionally join the mailing lists for that project or go into its IRC channel: you can make acquaintance with developers and your potential mentor, as well as start learning the codebase. We recommend strongly doing that.

Student proposal guidelines

A project proposal is what you will be judged upon. So, as a general recommendation, write a clear proposal on what you plan to do, what your project is and what it is not, etc. Several websites now contain hints and other useful information on writing up such proposals.

KDE does not require a specific format or specific list of information, but here are some specific points that you should address:

• Who are you? What are you studying?
• What exactly do you intend to do? What will not be done?
• Why are you the right person for this task?
• To what extent are you familiar with the software you're proposing to work with? Have you used it? Have you read the source? Have you modified the source?
• How many hours are you going to work on this a week? 10? 20? 30? 40? Do you have other commitments that we should know about?
• Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, not to mention 12 time zones away? How will you work with your mentor to track your work? Have you worked in this style before?
• If your native language is not English, are you comfortable working closely with a supervisor whose native language is English? What is your native language, as that may help us find a mentor who has the same native language?
• Where do you live, and can we assign a mentor who is local to you so you can meet in a coffee shop for lunch?

After you have written your proposal, you should get it reviewed. Do not rely on the KDE mentors to do it for you via the web interface: they will only send back a proposal if they find it lacking. Instead, ask a colleague or a developer to do it for you.

Hints

Submit your proposal early: early submissions get more attention from developers for the simple fact that they have more time to dedicate to reading them. The more people see it, the more it'll get known.

Do not leave it all to the last minute: while it is Google that is operating the webserver, it would be wise to expect a last-minute overload on the server. So, make sure you send your application before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a low vote because of that.

Keep it simple: we don't need a 10-page essay on the project and on you (Google won't even let you submit a text that long). You just need to be concise and precise.

Know what you are talking about: the least we need is for students to submit ideas that cannot be accomplished realistically or ideas that aren't even remotely related to KDE. If your idea is unusual, be sure to explain why you have chosen KDE to be your mentoring organisation.

Aim wide: submit more than one proposal, to different areas of KDE. We also recommend submitting to more than one organisation too. This will increase your chances of being chosen.

Instructions for mentors

Ideas

If you're a developer (KDE developer or not) and you wish to participate in Summer of Code, you can do it in two ways: the first and easiest is to make a proposal in the ideas page. Take a look at what your KDE project needs or what you feel KDE 4 should have. Feel free to submit ideas even if you cannot elaborate too much on them.

The second possibility is to be a mentor for a more specific idea. If you wish to do that, please read the instructions common to all participants and the Summer of Code FAQ. Also, please contact the maintainer for your application or module and get the go-ahead from him/her. Then edit the ideas page, adding your idea.

Your idea proposal should be a brief description of what the project is, what the desired goals would be, what the student should know and your email address for contact. Please note, though, that the students are not required to follow your idea to the letter, so regard your proposal as just a suggestion.

Note: when editing the wikipage, please make sure you're logged in (this is to make sure nobody is tampering with the ideas).

Mentoring

If you wish to help us even more, you can be a KDE mentor. You don't have to be a KDE developer to do that, but you do have to be a developer. We will potentially assign a student to you who has never worked on such a large project and will need some help. Make sure you're up for the task.

When subscribing yourself as a mentor, please make sure that your application or module maintainer is aware of that. Ask him/her to send the Summer of Code KDE Administrators an email confirming to know you. This is just a formality to make sure you are a real person we can trust -- the administrators cannot know all active developers by their Google account ID.

If you would like to get an idea of what is involved in being a good mentor, Federico Mena-Quintero has written some helpful information based on his experiences in previous years. His HOWTO has some useful suggestions for anyone planning to mentor this year, and is located at http://primates.ximian.com/~federico/docs/summer-of-code-mentoring-howto/index.html.

You will be subscribed to a mailing list to discuss ideas. We will also require you to read the proposals as they come in and you will be allowed to vote on the proposals, according to rules we will publish later.

Finally, know that we will never assign you to a project you do not want to work on. We will not assign you more projects than you can/want to take on either. And you will have a backup mentor, just in case something unforeseen takes place.

Instructions for module/application maintainers

If you are a maintainer of a particular sub-project within KDE, you may be contacted by developers in your project about an idea he wants to submit. This step is here only to make sure the developers are legitimate people involved in the project — KDE has become too big for the Summer of Code administrators to know each and every developer. Therefore, we delegate this task.

You should also judge whether the idea being proposed coincides with the general goals for your application/module. If you feel that is not the case, you should reply to your developer and suggest that he modify the proposal.

Also, please contact the administrators with your module/application name. If we receive an application in the Google web interface regarding your module, we'll need your input to judge whether the application makes sense or not, whether it should be improved or not, etc. We will also contact you for recruiting mentors if your application turns out to be very popular.

You do not need yourself to be a mentor, but we would like you to.

To reach the KDE administrators for Summer of Code, please send email to [email protected].