GSOC newcomers

From GCompris
Revision as of 19:54, 13 November 2016 by Dmadaan (talk | contribs) (→‎Setting your KDE account)
Jump to: navigation, search

Write a sok/gsoc proposal

You are a student and want to participate to either sok or gsoc. For this, you have to write a proposal on what you plan to do.

Important note: if you don't follow this, your application will not be considered.

Idea pages

There are several pages that can help you find what we'd like to see on GCompris:

If you have ideas that are not listed there, don't hesitate to propose them.

The aim is not to do everything. You have to keep in mind the time length of the event.

You need to describe what you plan to do (which activities, how, if possible have mock-ups...) and give a timeline for the project.

Send a mail to gcompris-devel@kde.org with a link to your proposal (github page, google doc, personal website...) and estimated timeline. In the timeline, don't forget that mentors have to review the changes and then changes will probably have to be done in the code.

Introduction to GCompris community

If you haven't gotten in touch previously, we ask new comers to do a little exercise: http://gcompris.net/wiki/An_exercise_for_new_contributors.

Proposal submission

The submission of the proposal must be done on the corresponding website before the deadline.

When accepted

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

If you haven't done it yet, 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/). Then you need to apply for a KDE Developer account (https://community.kde.org/Infrastructure/Get_a_Developer_Account#Apply_for_an_account) 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:

First step is to assign to yourself all the tasks you plan to do in https://phabricator.kde.org/project/view/1/.

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. please try to do a blog post at least every month.

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.
  • Follow coding rules and indent properly your code.
  • 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 languages. 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 "").
  • Prefix your commit messages by the activity name, i.e: "sudoku, fix bad anchor of the grid".

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.

Retrieved from "http://gcompris.net/mediawiki-1.31.0/index.php?title=GSOC_newcomers&oldid=4590"