GSoC: Difference between revisions

From KDE Community Wiki
(remove outdated program icon)
(→‎Ideas: 2024)
 
(83 intermediate revisions by 15 users not shown)
Line 1: Line 1:
[[Category:Mentoring]]
[[Category:Mentoring]]
[[File:Mascot konqi-app-presentation.png|thumbnail|right|[[Konqi]] is giving a lesson!]]
''[[/2024/Ideas|Ideas for GSoC 2024]]''


See also: '''[[/2013/Ideas|Ideas for GSoC 2013]]''', [[/2012/]],  [[/2011/]], [[/2010/]], [http://techbase.kde.org/Projects/Summer_of_Code previous GSoCs]
See also: [[/2023/]], [[/2022/]], [[/2021/]], [[/2020/]], [[/2019/]], [[/2018/]], [[/2017/]], [[/2016/]], [[/2015/]], [[/2014/]], [[/2013/]], [[/2012/]],  [[/2011/]], [[/2010/]], [http://techbase.kde.org/Projects/Summer_of_Code previous GSoCs]


All students and developers are welcome to participate in the Summer of Code program with KDE. Here's how.


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


== Instructions common to all participants ==
Mentors, administrators and students: read [https://developers.google.com/open-source/gsoc/ Summer of Code] occasionally. Also read the [https://developers.google.com/open-source/gsoc/faq Summer of Code FAQ].


All participants should take a look at the [http://code.google.com/p/google-summer-of-code/ 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. So, save time and create one now. In addition, all KDE students need to join the [https://mail.kde.org/mailman/listinfo/kde-soc KDE student list, KDE-Soc]. In addition, if you do not yet have a [https://identity.kde.org KDE account]; set that up now.
 
All participants will need a Google account in order to join the program. You'll save some time if you create one now.


=== Programming Language ===
=== Programming 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.
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.
C++ will be accepted for any project. Submissions and ideas for projects in any other language should specifically mention the choice.


== Instructions for students ==
== Instructions for potential contributors ==


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. 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.
People wishing to participate in Summer of Code must realise this is an important professional opportunity. You will be required to produce code for KDE during the coding period. Your mentors, KDE developers, will dedicate a portion of their time to mentoring you. Therefore, we seek candidates who are committed to helping KDE long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s).


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. The KDE community maintains a separate wiki page with general information about [[Getinvolved/development|getting started]] with KDE development.
You don't have to be a proven developer -- in fact, this whole program is meant to facilitate joining KDE and other Open Source communities. However, experience in coding and/or experience with KDE/Qt libraries and applications is welcome. The KDE community maintains a separate wiki page with general information about [[Getinvolved/development|getting started]] with KDE development. '''You are required to fix some bugs and link that work on your proposal'''. '''Proposals with no previous work with the KDE community will not be considered'''.  '''Proposals related to the current KDE goals are warmly welcomed'''.


You should 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. Note that the timeline from Google reserves a lot of time for bonding periods: use those periods wisely.
You should start learning the components that you plan on working on before the start date. KDE developers are available on mailing lists and on Matrix/IRC for help. The timeline from Google reserves a lot of time for bonding periods; use that time wisely. Good communication is key. You should plan to communicate with your team at least daily, and formally report progress and plans weekly. '''Contributors who neglect active communication will be failed'''.


=== General instructions ===
=== General instructions ===


First of all, please read the [[#Instructions common to all participants|instructions common to all participants]] and the GSoC FAQ. Pay special attention to the '''Eligibility''' section of the FAQ.
First of all, please read the [[#All_participants|instructions common to all participants]] and the [https://developers.google.com/open-source/gsoc/faq GSoC FAQ]. Pay special attention to the '''Eligibility''' section of the FAQ.


=== Recommended steps ===
=== Recommended steps ===


# Read Google's instructions for participating
# Join the [https://mail.kde.org/mailman/listinfo/kde-devel KDE-devel list] and [https://userbase.kde.org/IRC_Channels #kde-devel IRC channel], introduce yourself, and meet your fellow developers
# Take a look at the [[/2013/Ideas|list of ideas]]
# Read [https://developers.google.com/open-source/gsoc/ Google's instructions for participating] and the [https://google.github.io/gsocguides/student/ GSoC Student Manual]
# Take a look at the [[/2022/Ideas|list of ideas]]
# Come up with project that you're interested in
# Come up with project that you're interested in
# Write a first draft [[#Student proposal guidelines|proposal]] and get someone to review it for you
# Write a first draft [[#Student proposal guidelines|proposal]] and get someone to review it
# Submit it using Google's web interface
# Remember: you must link to work such as commits in your proposal
# Remember to explain your interest in KDE as an organization as well as the project
# Read [https://teom.wordpress.com/2012/03/01/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/ How to write a kickass proposal for GSoC]
# Submit your proposal using [https://summerofcode.withgoogle.com/ Google's web interface] ahead of the deadline
# Submit proof of [https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation eligibility] well ahead of the deadline
 
Coming up with an interesting idea is probably the most difficult part. It should be something interesting for KDE, for Open Source in general and for you. And it must be something that you can realistically achieve in the time available to you.
 
A good start is finding out what the most pressing issues are in the projects in which you are interested. Join the mailing lists for that project or go into its IRC channel: meet developers and your potential mentor, as well as start learning the codebase. We recommend strongly getting involved in advance of the beginning of GSoC, and we will look favorably on applications from students who have already started to act like Open Source developers.


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.
=== Potential contributor proposal guidelines ===


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 and we will look favourably on applications from students who have started to act like Open Source developers.
A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well. Proposals are ranked by project, so be sure to examine all suggested projects to increase your chances of selection.  The proposal is not only the basis of KDE's decision of which student to choose, it has also an effect on Google's decision as to how many student slots are assigned to KDE.  


=== Student proposal guidelines ===
Below is the application template.


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.
'''Introduction'''


KDE does not require a specific format or specific list of information, but there is an application template on the KDE page in Melange and here are some specific points that you should address in your application:
Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. Include links to discussions, features, or bugs that describe the problem further if necessary.
 
'''Project goals'''
 
Be short and to the point, and perhaps format it as a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the Google Summer of Code term is what counts.
 
'''Implementation'''
 
Be detailed. Describe what you plan to do as a solution for the problem you defined above. Include technical details, showing that you understand the technology. Illustrate key technical elements of your proposed solution in reasonable detail. Include writing unit tests throughout the coding period, as well as code documentation. These critical elements cannot be left to the last few weeks of the program. If user documentation will be required, or apidox, etc. these should be written during each week, not at the end.
 
'''Timeline'''
 
Show that you understand the problem, have a solution, have broken it down into manageable parts, and that you have a realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible. Your timeline should be detailed; week by week, precisely what you plan to do each week.
 
If you have other commitments during GSoC, such as a job, vacation, exams, internship, seminars, or papers to write, disclose them here. GSoC should be treated like a full-time job, and we will expect approximately 40 hours of work per week for half the coding period, or 20 hours over the duration. ''If you have conflicts, explain how you will work around them.'' If you are found to have conflicts which you did not disclose, you may be failed.
 
Open and clear communication is of utmost importance. '''Include your plans for communication in your proposal; daily if possible.''' You will need to initiate weekly formal communication such as a blog post on the KDE Planet or detailed email to the team mail list. Lack of communication will result in you being failed.
 
'''About me'''
 
Provide your contact information (IRC nick, email, IM, phone) and write a few sentences about you and why you think you are the best for this job. '''Prior contributions to KDE are required; list your commits.'''  Name people (other developers, students, professors) who can act as a reference for you. Mention your field of study if necessary. Now is the time to join the relevant Matrix/IRC channels, mail lists and blog feeds. We want you to be a part of our community, not just contribute your code.
 
''Tell us if you are submitting proposals to other organizations, and whether or not you would choose KDE if given the choice.''
 
''Other things to think about:''
 
* Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, and perhaps 12 time zones away? How will you work with your mentor to track your work? Have you worked in this style before?


* 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? If so, please suggest a way to compensate if it will take much time away from Summer of Code.
* 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?
* 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.
* 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, although we will try to comment on every proposal. It is wise to ask a colleague or a developer to critique your proposal. Clarity and completeness are important.


=== Hints ===
=== 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.
'''Submit your proposal early''': early submissions get more attention from developers because that they have more time to read them. The more people see your proposal, the more it will be discussed.
 
'''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, be sure you send your application and proof of enrollment before the final rush. Also, applications submitted very late will get the least attention from mentors, so you may get a lower vote because of that. Submitting a draft early will give time for feedback from prospective mentors.


'''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''': Be concise and precise. Provide a clear, descriptive title. "My Project" is the worst possible title!


'''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''': Do not submit proposals that cannot be accomplished over a summer or that are not related to KDE. If your idea is unusual, be sure to explain why you have chosen KDE to be your mentoring organisation.


'''Know what you are talking about''': the last thing 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, in different areas of KDE. You are allowed to submit to another organisation as well. If you do submit more than one proposal, tell us that and which proposal you would choose, if both were selected. Former students would advise you to do one or two kick-ass proposals rather than trying to do three.


'''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.
=== Accepted Contributors ===


The PostgreSQL project has also released a [http://www.postgresql.org/developer/summerofcodeadvice.html list of hints] that you can take a look.
Your primary responsibility is finishing your project under the guidance of your mentors. To do that, you must submit code regularly and stay in frequent and effective communication with your mentors and team. To pass the evaluations, you must do both the communication '''and''' the coding plus documentation.
 
All contributors will create a report page linked from here: [https://community.kde.org/GSoC/2022/StatusReports Status Reports]. Keep this up-to-date, as this is one of our primary evaluation tools. Ensure that your blogs are on the [https://planetkde.org/ KDE Planet] and linked on the status page.


== Instructions for mentors ==
== Instructions for mentors ==


=== Ideas ===
=== 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 [[GSoC/2012/Ideas|ideas page]]. Take a look at what your KDE project needs or what you feel KDE should have. Feel free to submit ideas even if you cannot elaborate too much on them.
If you're a KDE developer and you wish to participate in Summer of Code, make a proposal in the [[GSoC/2024/Ideas|ideas page]], based what your KDE project needs.


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|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.
If you wish to mentor, please read the [[#All_participants|instructions common to all participants]] and the [https://developers.google.com/open-source/gsoc/faq#general Summer of Code FAQ]. Also, please contact the maintainer for your application or module and get the go-ahead from hir before editing 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.
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 an email address for contact. Students are not required to follow your idea to the letter, so regard your proposal as inspiration for the students.


=== Mentoring ===
=== Mentoring ===
If you wish to help us even more, you can be a KDE mentor. 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.
Any KDE developer can be a mentor if you meet the GSoC eligibility requirements. 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. Mentoring takes time, and lots and lots of communication.


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.
Before subscribing yourself as a mentor, please make sure that your application or module maintainer is aware of that. Ask them to send the Summer of Code KDE Administrators an email confirming your involvement in the team. 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. Then ping us in IRC #kde-soc, Matrix #kde-soc:kde.org or [mailto:[email protected] mail].


If you would like to get an idea of what is involved in being a good mentor, be sure to read the [http://www.booki.cc/gsoc-mentoring mentoring guide]. Also, Federico Mena-Quintero has written some helpful information based on his experiences in previous years. [http://primates.ximian.com/~federico/docs/summer-of-code-mentoring-howto/index.html His HOWTO] has some useful suggestions for anyone planning to mentor this year.
Prospective mentors should read the [http://www.booki.cc/gsoc-mentoring mentoring guide]. Also, Federico Mena-Quintero has written some helpful information based on his experiences in previous years. [https://people.gnome.org/~federico/docs/summer-of-code-mentoring-howto/index.html His HOWTO] has some useful suggestions for anyone planning to mentor this year.


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.
You will subscribe to the [https://mail.kde.org/mailman/listinfo/kde-soc-mentor KDE-Soc-Mentor] mailing list to discuss ideas. You will need to read the proposals as they come in, and vote on the proposals, according to guidelines discussed on KDE-Soc-Mentor. Daily communication is required with your student during the Community Bonding period, and multiple times per week during the coding period.


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.
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.


=== Subscribing as mentor ===
=== Signing up as a mentor ===


To subscribe as mentor, you need to complete a few easy steps.
To become a  mentor:


:# Contact the administrators in #kde-soc on freenode to let them know which project you want to mentor for
:# Contact the administrators in #kde-soc on Freenode to let them know for which project you want to mentor and give us your google-connected account email
:# Log in to [http://www.google-melange.com Melange]
:# Log in to [https://summerofcode.withgoogle.com GSoC webapp] after being added as a mentor by one of the admins
:# Apply as a mentor for KDE
:# Subscribe to [https://mail.kde.org/mailman/listinfo/kde-soc-mentor KDE-soc-mentor mail list]
:# Subscribe to kde-soc-mentor at kde org


== Instructions for module/application maintainers ==
== 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.
If you are a maintainer of a particular sub-project within KDE, you may be contacted by developers in your project about an idea they want 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 rely on you.
   
   
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.
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 they 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.
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 decide 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 help us out.
 
To reach the KDE administrators for Summer of Code, please write [email protected].
 
== See also ==
 
[[SoK|Season of KDE]]
 
== External links ==
 
[https://developers.google.com/open-source/gsoc/ Google Summer of Code]
 
[https://developers.google.com/open-source/gsoc/faq Google Summer of Code FAQ]


You do not need yourself to be a mentor, but we would like you to.
[https://mail.kde.org/mailman/listinfo/kde-soc KDE-Soc (KDE student mailing list)]


To reach the KDE administrators for Summer of Code, please send email to kde-soc-mentor@kde.org.
[https://mentorship.kde.org/ KDE's Mentorship Website]

Latest revision as of 22:04, 10 February 2024

Konqi is giving a lesson!

Ideas for GSoC 2024

See also: 2023, 2022, 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, previous GSoCs

All students and developers are welcome to participate in the Summer of Code program with KDE. Here's how.

All participants

Mentors, administrators and students: read Summer of Code occasionally. Also read the Summer of Code FAQ.

All participants will need a Google account in order to join the program. So, save time and create one now. In addition, all KDE students need to join the KDE student list, KDE-Soc. In addition, if you do not yet have a KDE account; set that up now.

Programming 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.

Instructions for potential contributors

People wishing to participate in Summer of Code must realise this is an important professional opportunity. You will be required to produce code for KDE during the coding period. Your mentors, KDE developers, will dedicate a portion of their time to mentoring you. Therefore, we seek candidates who are committed to helping KDE long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s).

You don't have to be a proven developer -- in fact, this whole program is meant to facilitate joining KDE and other Open Source communities. However, experience in coding and/or experience with KDE/Qt libraries and applications is welcome. The KDE community maintains a separate wiki page with general information about getting started with KDE development. You are required to fix some bugs and link that work on your proposal. Proposals with no previous work with the KDE community will not be considered. Proposals related to the current KDE goals are warmly welcomed.

You should start learning the components that you plan on working on before the start date. KDE developers are available on mailing lists and on Matrix/IRC for help. The timeline from Google reserves a lot of time for bonding periods; use that time wisely. Good communication is key. You should plan to communicate with your team at least daily, and formally report progress and plans weekly. Contributors who neglect active communication will be failed.

General instructions

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

Recommended steps

  1. Join the KDE-devel list and #kde-devel IRC channel, introduce yourself, and meet your fellow developers
  2. Read Google's instructions for participating and the GSoC Student Manual
  3. Take a look at the list of ideas
  4. Come up with project that you're interested in
  5. Write a first draft proposal and get someone to review it
  6. Remember: you must link to work such as commits in your proposal
  7. Remember to explain your interest in KDE as an organization as well as the project
  8. Read How to write a kickass proposal for GSoC
  9. Submit your proposal using Google's web interface ahead of the deadline
  10. Submit proof of eligibility well ahead of the deadline

Coming up with an interesting idea is probably the most difficult part. It should be something interesting for KDE, for Open Source in general and for you. And it must be something that you can realistically achieve in the time available to you.

A good start is finding out what the most pressing issues are in the projects in which you are interested. Join the mailing lists for that project or go into its IRC channel: meet developers and your potential mentor, as well as start learning the codebase. We recommend strongly getting involved in advance of the beginning of GSoC, and we will look favorably on applications from students who have already started to act like Open Source developers.

Potential contributor proposal guidelines

A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well. Proposals are ranked by project, so be sure to examine all suggested projects to increase your chances of selection. The proposal is not only the basis of KDE's decision of which student to choose, it has also an effect on Google's decision as to how many student slots are assigned to KDE.

Below is the application template.

Introduction

Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. Include links to discussions, features, or bugs that describe the problem further if necessary.

Project goals

Be short and to the point, and perhaps format it as a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the Google Summer of Code term is what counts.

Implementation

Be detailed. Describe what you plan to do as a solution for the problem you defined above. Include technical details, showing that you understand the technology. Illustrate key technical elements of your proposed solution in reasonable detail. Include writing unit tests throughout the coding period, as well as code documentation. These critical elements cannot be left to the last few weeks of the program. If user documentation will be required, or apidox, etc. these should be written during each week, not at the end.

Timeline

Show that you understand the problem, have a solution, have broken it down into manageable parts, and that you have a realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible. Your timeline should be detailed; week by week, precisely what you plan to do each week.

If you have other commitments during GSoC, such as a job, vacation, exams, internship, seminars, or papers to write, disclose them here. GSoC should be treated like a full-time job, and we will expect approximately 40 hours of work per week for half the coding period, or 20 hours over the duration. If you have conflicts, explain how you will work around them. If you are found to have conflicts which you did not disclose, you may be failed.

Open and clear communication is of utmost importance. Include your plans for communication in your proposal; daily if possible. You will need to initiate weekly formal communication such as a blog post on the KDE Planet or detailed email to the team mail list. Lack of communication will result in you being failed.

About me

Provide your contact information (IRC nick, email, IM, phone) and write a few sentences about you and why you think you are the best for this job. Prior contributions to KDE are required; list your commits. Name people (other developers, students, professors) who can act as a reference for you. Mention your field of study if necessary. Now is the time to join the relevant Matrix/IRC channels, mail lists and blog feeds. We want you to be a part of our community, not just contribute your code.

Tell us if you are submitting proposals to other organizations, and whether or not you would choose KDE if given the choice.

Other things to think about:

  • Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, and perhaps 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?
  • 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, although we will try to comment on every proposal. It is wise to ask a colleague or a developer to critique your proposal. Clarity and completeness are important.

Hints

Submit your proposal early: early submissions get more attention from developers because that they have more time to read them. The more people see your proposal, the more it will be discussed.

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, be sure you send your application and proof of enrollment before the final rush. Also, applications submitted very late will get the least attention from mentors, so you may get a lower vote because of that. Submitting a draft early will give time for feedback from prospective mentors.

Keep it simple: Be concise and precise. Provide a clear, descriptive title. "My Project" is the worst possible title!

Know what you are talking about: Do not submit proposals that cannot be accomplished over a summer or that are not 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, in different areas of KDE. You are allowed to submit to another organisation as well. If you do submit more than one proposal, tell us that and which proposal you would choose, if both were selected. Former students would advise you to do one or two kick-ass proposals rather than trying to do three.

Accepted Contributors

Your primary responsibility is finishing your project under the guidance of your mentors. To do that, you must submit code regularly and stay in frequent and effective communication with your mentors and team. To pass the evaluations, you must do both the communication and the coding plus documentation.

All contributors will create a report page linked from here: Status Reports. Keep this up-to-date, as this is one of our primary evaluation tools. Ensure that your blogs are on the KDE Planet and linked on the status page.

Instructions for mentors

Ideas

If you're a KDE developer and you wish to participate in Summer of Code, make a proposal in the ideas page, based what your KDE project needs.

If you wish to mentor, 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 hir before editing 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 an email address for contact. Students are not required to follow your idea to the letter, so regard your proposal as inspiration for the students.

Mentoring

Any KDE developer can be a mentor if you meet the GSoC eligibility requirements. 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. Mentoring takes time, and lots and lots of communication.

Before subscribing yourself as a mentor, please make sure that your application or module maintainer is aware of that. Ask them to send the Summer of Code KDE Administrators an email confirming your involvement in the team. 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. Then ping us in IRC #kde-soc, Matrix #kde-soc:kde.org or mail.

Prospective mentors should read the mentoring guide. Also, 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.

You will subscribe to the KDE-Soc-Mentor mailing list to discuss ideas. You will need to read the proposals as they come in, and vote on the proposals, according to guidelines discussed on KDE-Soc-Mentor. Daily communication is required with your student during the Community Bonding period, and multiple times per week during the coding period.

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.

Signing up as a mentor

To become a mentor:

  1. Contact the administrators in #kde-soc on Freenode to let them know for which project you want to mentor and give us your google-connected account email
  2. Log in to GSoC webapp after being added as a mentor by one of the admins
  3. Subscribe to KDE-soc-mentor mail list

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 they want 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 rely on you.

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 they 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 decide 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 help us out.

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

See also

Season of KDE

External links

Google Summer of Code

Google Summer of Code FAQ

KDE-Soc (KDE student mailing list)

KDE's Mentorship Website