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. Other Important note: Do not start working on the tasks before the selection process is done. Several students may want to propose for the same task and it wouldn't be fair to them to block the task.
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. For each activity:
The final realisation could be different from what is planned at the beginning but this step is important for you and for us.
Review process and corrections take time. In reality as much as the first code completion. Take this fact into account when doing your timeline. We prefer realistic plans! If you plan to work on several activities, due to review time, at one point of the project you will have to work on them in parallel.
Send a mail to firstname.lastname@example.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.
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.
The submission of the proposal must be done on the corresponding website before the deadline.
In order to avoid missing steps, refer to this table before submitting your proposal.
|Steps to do||Done|
|Write project general purpose,|
|Draw mockup for each screen,|
|Describe the different objects of a view and their interactions,|
|Provide a realistic timetable for each project sub part,|
|Write down basic tests for each project sub part,|
The selection process is difficult for both mentors and students. All the students can't be accepted due to number limitations (number of mentors, slots granted by Google...).
On mentors side, we select students depending on several criterias like code quality, autonomy, implication in the project... If you are not selected, try to not take it as personal failure: for sure, depending on your involvment, it can be hard to accept. But mentors have to make a choice, a difficult one, to select people with their given information.
Do not only consider a GSoC application as your only potential "internship" (it's not an intership: https://developers.google.com/open-source/gsoc/faq) as you are not sure of being selected.
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.
If you haven't done it yet, send a mail to email@example.com to introduce yourself:
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/.
You can see the git at https://phabricator.kde.org/source/gcompris/ (or https://cgit.kde.org/gcompris.git if you are not connected). As you will push work on it, you need to clone firstname.lastname@example.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.
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).
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:
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 :
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.
As mentioned earlier review requires a lot of time. Again a quick check table to help you before submitting a review request.
|Steps to do||Done|
|Every file must have a license header with your name on it if you wrote it.|
|Every strings that should be translated must be between qsTr().|
|Variable names and files must "tell' what they do. pointImageRepeater is prefereble to repeater.|
|Prefix your commit messages by the activity name, i.e: "sudoku, fix bad anchor of the grid".|
|Clean unused variables or files.|
|Indent properly your code.|
In order to avoid too early commitment to GSoc 2018, we decided to set a date before which we will not take in account any proposal or discussion about GSoc.
This is important to avoid competition between GCompris contributors.
In order to select next year GSoc proposals, code quality (code cleverness, variable names, comments) will be as important as involvement.
Please understand that we will not accept any discussion about GSoc before February 16th 2018.