GSoC overview

(Code and tickets)
(+github -dead link)
 
Line 24: Line 24:
The main prerequisite for working on SuperTuxKart is good C++ knowledge. You will also want to get familiar with our [https://github.com/supertuxkart/stk-code/issues?state=open bug tracker].
The main prerequisite for working on SuperTuxKart is good C++ knowledge. You will also want to get familiar with our [https://github.com/supertuxkart/stk-code/issues?state=open bug tracker].
-
At this stage you need a sourceforge account in order to submit a ticket. The chances of a proposal to be accepted can be increased if you submit a patch first. This allows us to evaluate your coding style, way of documenting etc.  Even if you don't find a ticket you want to work on (admittedly many of our tickets would require some work), feel free to open a ticket yourself, and submit a patch for it. One simple example would be to improve [[Coding_Style | coding style issues]] in a file, or improve documentation - there are still some older files which were not brought up-to-date with latest coding style changes. If you are looking for more of a challenge, try to implement an achievement. The achievement infrastructure is the result of the 2013 GSoC, and achievements will be contained in the next release of STK. So we are always looking for more achievements. Have a look at the files in src/achievements for more details. In any case, please discuss the ticket with us first, we can help in identifying tickets appropriate for your skill level.  
+
At this stage you need a github account in order to submit a ticket. The chances of a proposal to be accepted can be increased if you open a pull-request first. This allows us to evaluate your coding style, way of documenting etc.  Even if you don't find a ticket you want to work on (admittedly many of our tickets would require some work), feel free to open a ticket yourself, and submit a patch for it. One simple example would be to improve [[Coding_Style|coding style issues]] in a file, or improve documentation - there are still some older files which were not brought up-to-date with latest coding style changes. If you are looking for more of a challenge, try to implement an achievement. The achievement infrastructure is the result of the 2013 GSoC, and achievements will be contained in the next release of STK. So we are always looking for more achievements. Have a look at the files in src/achievements for more details. In any case, please discuss the ticket with us first, we can help in identifying tickets appropriate for your skill level.  
-
Any contributions to SuperTuxKart must be in clean and portable C++. They should also compile without any warnings. We don't expect that a student to be able to check his code on all supported platforms - our community will do this and fix any minor issues that should occur when using a different compiler. Please also have a look at some of our [[Portability_concerns | portability advise]].
+
Any contributions to SuperTuxKart must be in clean and portable C++. They should also compile without any warnings. We don't expect that a student to be able to check his code on all supported platforms - our community will do this and fix any minor issues that should occur when using a different compiler.
 +
 
 +
We have started to use travis-ci - which means that as soon as anything is committed to our GitHub repository, travis-ci will compile on linux and report any problems. You can also activate travis-ci for your own repository.
 +
 
 +
=== How to get prepared for submitting a proposal ===
 +
 
 +
If you are new to GSOC, you may wonder where to start. Here are the obvious starting points :
 +
* Play the game! If you spend some time playing SuperTuxKart and get to know the game, you will get insight on the project and your proposal will be of much higher quality.
 +
* Download the sources from git and the assets from SVN ( see [[Source_control]] ) and compile the game from sources ( instructions for Windows, OSX and Linux can be found on [[Get_involved]] )
 +
* Take a quick look at our [http://supertuxkart.sourceforge.net/doxygen/?title=doxygen Doxygen documentation] to get a quick overview of the code. Note that this documentation is not always fully up to date, but the idea here is only to get an idea of what are the various modules of the game and how they relate to each other.
 +
* Decide what you would like to work on. Our [[GSoC_topics_2014|ideas list]] is a good place to start at, but you can also come up with your own ideas (better to discuss them with us before investing a lot of energy on it, though!)
 +
* Investigate on your idea. Get to know a broad overview of the relevant code if possible/relevant; research solutions (algorithms, implementations, designs); think of use cases, possible problems, how to solve them. What will be expected of students is to produce an analysis that shows you understand the problem to solve, and you propose a workable and realistic way to solve it. Identifying constraints, risks, time estimates, explaining design choices, etc. may help produce a more complete analysis. Important to note is that we are not expecting a perfect analysis; demonstrating a good sense of logic and thorough analysis is what we are most interested in finding in students.
 +
 
 +
 
 +
How we will help you through this process :
 +
 
 +
* Don't worry though, you are not alone in the process! We are here to help you in the process of analyzing the task and coming up with solutions. You can contact us on the mailing list or IRC channel as explained in more details later. That being said, it is also important that we clarify how we will be helping you.
 +
* First of all, a starting note. If this year is anything like last year, we expect that a lot of students will be interested in SuperTuxKart - last year we had around 70 proposals. (This does means you will likely have a lot of competition; but don't let that put you down, because a very large part of proposals we received were also low quality. So if you invest genuine effort in a good proposal, you have a very real chance of making it to the top.)
 +
* Because of the high interest, the period where students ask questions are usually very crowded for us. For this reason, and also because want to know what you are capable of without us giving you all the answers, we will focus our help in some specific directions.
 +
** First rule, this kind of email or IRC comment should be avoided : "Hi! I am interested in your project. Where do I start?". Start by showing us that you are capable of starting a project without hand holding. For instance, a much more interesting question would be "Hi, I would be interested in working on project <X>, I was thinking of using solution <Y> but I am not sure if this solution would integrate well in the current code base. I took a quick look at the code and I see that you are using technique <Z>, do you foresee problems I may not have anticipated in integrating <Y> into the current system?"
 +
** Again for the reasons stated above, our role will be to guide you in the right direction, not to give you the answers. We will gladly help you understand our needs and the current implementation (what is currently in place); however we will likely not be as specific when discussing the new portions. The reason for this is of course that we are interesting in seeing what you can bring to the table.
 +
** In later phases, you can show us a draft of your proposal for review, and we will comment on ways you can improve it. For obvious, we will not compare you to other students. Due to time constraints, we are also unable to repeatedly review your proposal drafts, therefore please make sure the draft is in an advanced state before asking us for a complete review. Of course common sense applies here, if you rewrite a specific of the proposal after the initial review we can take another look at this specific section. We will however generally not fully review a student's proposal more than once
-
We have started to use travis-ci - which means that as soon as anything is committed to our GitHub repository, travis-ci will compile on linux and report any problems.
 
=== Required information ===
=== Required information ===
Line 41: Line 61:
* What platform do you usually work on?
* What platform do you usually work on?
* One-line project summary
* One-line project summary
-
* Detailed project description (a few paragraphs to one page)
+
* Detailed project description, analysis and implementation plan (suggested length: 2 to 5 pages)
* A rough roadmap and timeline of the planned development
* A rough roadmap and timeline of the planned development
** Before the actual programming start, we want to have a more detailed timeline, including milestones/deliverables
** Before the actual programming start, we want to have a more detailed timeline, including milestones/deliverables

Latest revision as of 08:48, 14 August 2014

Retrieved from "http://supertuxkart.sourceforge.net/GSoC_overview"

User Tools