In this page we document the process by which the developers of the project collaborate and get things done. If you're interested in contributing or getting involved please consider the guidelines and tips that are outlined in this page. Please check-in often as we flesh out this document further.
The first thing contributors and developers have to do is introduce themselves to the community. We'd like to have all contributors involved in the decision making process with regards to the development of GCompris.
If you haven't yet, please subscribe to the GCompris mailing list and introduce yourself before proceeding.
The maintainers of the project review and Merge Requests (Known as Pull Request on GitHub) from contributors. This allows the project to move forward using the Git distributed development workflow. If you need an introduction to git, please refer to the following links for git-specific information.
ProGit — a website dedicated to basic and advanced git usage. GitHub Git Setup — the GitHub help pages on setting up git to work with GitHub.
What follows in this section assumes that you're already familiar with the basic git workflow.
The official repository on cgit.kde.org requires a KDE developer account. We will ask regular contributor to get an account and work on the KDE repository.
Before that, the best way is to send us a diff with your changes, using https://phabricator.kde.org/differential/diff/create/ .
For developers interested only in small and occasional contribution, a push request from github can be accepted.
Forking requires that you already have an account. Before you can submit Merge or Pull Requests you should first create your own fork of the repository. You can fork the repository by clicking on the Fork button on the repository page.
After creating a Diff to ask for a review on phabricator, please always edit it to add the corresponding group in Reviewers (it can be GCompris, GCompris:Bugs, GCompris: Improvements, ... please select the most appropriate one for your patch).
Also, please always send screenshots showing your changes (one before and one with the changes). This will help us to notice quickly any big issue, and to understand easily what is the goal of the patch.
Once you have a fork of the repo, determine to which branch you'd like to send a Merge / Pull Request to. In the next section we describe the various branches we'll be dealing with in the course of development of a release.
When you've determined the branch to which you'd like to send a Merge / Pull Request to you can follow these steps to prepare your change for inclusion in GCompris.
In case you have multiple requests in flight, you may want to have multiple integration branches — that is, one integration branch per request should be good to keep.