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. For new developers or those interested only in a small contribution you can create an account on GitHub and work on it (it's free for open source projects).
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.
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.