Difference between revisions of "GSoC Ideas"

This is just the few projects that we have come with ourselves, and there are many many other tasks which would be helpful to the project - many ScummVM engines have their own TODO lists, and some large tasks are available related to ResidualVM engines.

You must follow our [[Coding Conventions]]. In particular, note that you can't use the standard C++ library for code used inside ScummVM itself. Using it for a non-essential tool should be fine, though.

All code, unless stated differently (for example, platform-specific code), must be written in clean and portable C++; in particular, various versions of both GCC and Visual Studio must be able to compile it. We also have some [[Code Formatting Conventions]].

We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend, than a complete but unmaintainable piece of code.

Finally: All of the code submitted must be contributed under the terms of the GPL v2+.

The ideas here are meant to be just that - '''ideas'''. You should also consider suggesting your own completely new project ideas, or to suggest a modified version of one of our ideas, or a combination of ideas. Not all the ideas might be substantial enough for the whole of GSoC, while other ideas might be far too much work. We expect you to consider this in your application and proposed schedule.

Your application should have at least the following information (adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines]):

* '''Name'''

* '''Email'''

* '''Online nicks'''

: Please list the nicknames of the communication channels you plan to use to keep in touch with us. For example, list your IRC (on FreeNode) nick here.

* '''Project Title'''

: State precisely what your project is about. 40 characters is usually a good upper limit.

* '''Possible Mentor''' (optional)

* '''Benefits to the ScummVM Community'''

: A good project will not just be fun to work on, but also generally useful to others.

* '''Deliverables'''

: The deliverables will be used to evaluate your progress/success at the mid-term/final evaluations. Thus, it is very important to list quantifiable results here (this does not need to be a simple list!) e.g.

:* "Improve X modules in ways Y and Z."

:* "Write 3 new man pages for the new interfaces."

:* "Improve performance in FOO by X%."

: Make sure there is a clearly visible set of '''goals''' that need to be accomplished for your project to be considered successful. It is also encouraged to list additional goals you plan to accomplish in the course of your project if everything goes as expected. You already explained why your project is beneficial for us, however, here you should motivate why a goal is required for your success or just optional. Make sure not to mix the description of a goal with this.

: In addition to the mere goals of your project define '''milestones'''. A milestone should be connected to the progress/accomplishment of goals. You should, at the very least, define 2 (two) milestones here. Again, describe the milestones and elaborate on your reasons for defining exactly these milestones. When you plan to accomplish the milestones will be handled in the schedule and not here.

* '''Project Schedule'''

: Create a proposed schedule with (at least) the granularity of weeks. This schedule should (among other things) explain how long your project will take and when you can begin to work on it, and you should connect the weeks to the Summer of Code schedule, i.e. clearly make the start, mid-term evaluations, etc. visible. There are multiple ways to organize this, we trust you to find the best way to present your schedule. Obviously we want to see a connection between your goals and your schedule: be sure to elaborate why you think X takes time Y and what possible issues might arise here; obviously your schedule will probably change once you've started working on your project, so we want to know what kind of risks and problems you think might cause such changes. Last but not least, put a fixed date for each milestone you defined here. We want at least one milestone before the mid-term.

* '''Availability'''

: How many hours per week can you spend working on this? What other obligations do you have this summer?

* '''Skype ID'''

* '''Phone Number'''

* '''Timezone'''

* '''Bio'''

* '''Pull Request'''

When writing this application, keep in mind that the application serves multiple purposes. First of all, it should identify the objectives of your project, i.e. what should be done. Furthermore, it needs to convince us your project is worth a slot/mentoring. Last but not least, it should convince us that you are indeed the right person for this task. A good example of what we do not want to see in your application is a copy of our version of an idea's description.