GSOC newcomers

Congratulations, you have been selected to participate to GCompris GSOC or SoK. Here are a few links to start your community bonding period and set up your environment.

Introduction to GCompris community

Send a mail to gcompris-devel@kde.org to introduce yourself:

• Name, country, university... Whatever you want to share that can be useful.
• Describe what you plan to do in GCompris, which part of GCompris will you improve...

Setting your KDE account

If you don't have one, you need to create a KDE account (https://identity.kde.org/) and ask for a developer access (precise that you will do GSOC/SoK under GCompris). More information can be found at https://community.kde.org/Sysadmin/GitKdeOrgManual#How_to_get_read-write_developer_access

We also plan to use https://phabricator.kde.org/ to track our progress so you'll also need an account. It provides a lot of useful tools:

• https://phabricator.kde.org/paste/ to paste text (crash reports, code snippets...)
• https://phabricator.kde.org/differential/ for code review
• https://phabricator.kde.org/conpherence/ for having multiple people conversations
• https://phabricator.kde.org/maniphest/ to create tasks and follow their achievements

Using git on KDE

You can see the git at https://phabricator.kde.org/diffusion/GCOMPRIS/ (or http://quickgit.kde.org/?p=gcompris.git if you are not connected). As you will push work on it, you need to clone git@git.kde.org:gcompris.git.

You can create a branch for your gsoc: git checkout -b mybranch and work on it. Don't forget to rebase on master from time to time. Once you think you finished your activity, you need to create a code review for mentors to comment the code.

Informing on your progress

In a work, the most important thing is communication. Without it, we can't know what the other people are doing, if they have issues... Do not hesitate to discuss as long as you have issues to be sure you've understood and fixed all of them.

Also, you need to create a blog detailing what you have done and add your blog posts to https://planetkde.org/ in order to the KDE community to follow what you've done. If you do not have one, you can create one using https://pages.github.com/ or Wordpress.

Moreover, using maniphest phabricator, you can describe precisely what you will do, state your task status and this will permit us and you to see where you are in your timeline (late or in advance).

Code quality

We hope that GCompris will be maintained for years if not decades. It is thus important that your code is clean enough to be reviewed and amended by anyone knowing Qt Quick.

Here are some points you have to check:

• Copyright headers in each source file must contain your copyright if you create them
• Once your code is done, make some clean up, there should not be any unused variable or file.
• Avoid files with many global variables or functions with too many parameters. This indicates that there is something wrong in your code.
• Avoid repeated code. There is an option in Qt Creator to refactor a QML object. It will be put in a dedicated file named after the object id (right click -> refactoring).
• Try to follow an object orientated approach by putting javascript functions specific to a QML object within the object itself instead of the global javascript file. This makes it easy to see what's possible to do with a Qml object.
• The preferred graphic format is SVG.
• If you take content from the Internet, graphics, sounds or anything it must be credited in a README file in the resource directory. It must name the file, the copyright and the link where you took it. the copyright must be compatible with the GPL.
• We rely on a lot on graphics but not everyone is skilled enough to make them. The good practise is to re-use existing graphics from GCompris (you can easily mix and change SVG files with Inkscape). If no graphic come close to what you need, the first place to check is http://openclipart.org
• If you don't find open content good enough don't worry, the GCompris graphic team will redo them when your activity is ready.
• GCompris is translated in many language. Thus, we need to take care of it in the code. All the strings that should be translated must be between qsTr(). Don't put variables in qsTr(), only real strings (in "").

Development workflow

Once you have your KDE account you have commit rights on the GCompris repository and on other KDE projects. But you must not commit on the master branch directly, you must notice the maintainers of GCompris that you are ready and the review process will start.

Your development must be done in a specific branch on the KDE GCompris git. Name your branch with the following scheme :

• [sok|gsoc]_[nickname]_[activity_name]

As we mention, code quality is of major importance. When you get review feedback change your code accordingly and tell you are ready for another review. Understand that it takes time to make review, so please take in account all our remarks and take time to refactor your code to make it clean, simple, logical and easy to read.