Contributing — Kivy v1.0.1-dev documentation

# Contributing

There are many ways in which you can contribute to Kivy. Code patches are just one thing amongst others that you can submit to help the project. We also welcome bug reports, feature requests, documentation improvements, advertisement & advocating, testing, graphics contributions and many different things. Just talk to us if you want to help, and we will help you help us.

## Code Contributions

Code contributions (patches, new features) are the most obvious way to help with the project’s development. Since this is so common we ask you to follow our workflow to most efficiently work with us. Adhering to our workflow ensures that your contribution won’t be forgotten or lost. Also, your name will always be associated with the change you made, which basically means eternal fame in our code history (you can opt-out if you don’t want that).

### Git & GitHub

We use git as our version control system for our code base. If you have never used git or a similar DVCS (or even any VCS) before, we strongly suggest you take a look at the great documentation that is available for git online. The Git Community Book or the Git Screencasts are both great ways to learn git. Trust us when we say that git is a great tool. It may seem daunting at first, but after a while you’ll (hopefully) love it as much as we do. Teaching you git, however, is well beyond the scope of this document.

Also, we use GitHub to host our code. In the following we will assume that you have a (free) GitHub account. While this part is optional, it allows for a tight integration between your patches and our upstream code base. If you don’t want to use GitHub, we assume you know what you do anyway.

### Code Workflow

So here is the initial setup to begin with our workflow (you only need to do this once to install Kivy). Basically you follow the installation instructions from Installing Kivy for Development, but you don’t clone our repository, but the fork you create with the following steps:

> 1. Log in to GitHub
> 2. Create a fork of the Kivy repository by clicking the fork button.
> 3. Clone your fork of our repository to your computer. Your fork will have the git remote name ‘origin’ and you will be on branch ‘master’.
> 4. Compile and set up PYTHONPATH or install (see Installing Kivy for Development).
> 5. Install our pre-commit hook that ensures your code doesn’t violate our styleguide by executing ‘make hook’ in your clone. This will run our styleguide check whenever you do a commit, and if there are violations in the parts that you changed, your commit will be aborted. Fix & retry.

Now, whenever you want to create a patch, you follow the following steps:

> 1. See if there is a ticket in our bug tracker for the fix or feature and announce that you’ll be working on it if it doesn’t yet have an assignee.
> 2. Create a new, appropriately named branch in your local repository for that specific feature or bugfix. (Keeping a new branch per feature makes sure we can easily pull in your changes without pulling any other stuff that is not supposed to be pulled.)
> 3. Modify the code to do what you want (e.g., fix it).
> 4. Test the code. Try to do this even for small fixes. You never know whether you have introduced some weird bug without testing.
> 5. Do one or more minimal, atomic commits per fix or per feature. Minimal/Atomic means keep the commit clean. Don’t commit other stuff that doesn’t logically belong to this fix or feature. This is NOT about creating one commit per line changed. Use `git add -p` if necessary.
> 6. Give each commit an appropriate commit message, so that others who are not familiar with the matter get a good idea of what you changed.
> 7. Once you are satisfied with your changes, merge with our upstream repository. We can pull your stuff, but since you know best what you changed, you should do the merge.
> 8. Push to your remote repository on GitHub.
> 9. Send a Pull Request with a description of what you changed via the button in the GitHub interface of your repository. (This is why we forked initially. Your repository is linked against ours.)
> Note:
>   When you change parts of the code base that require compilation, you will have to recompile in order for your changes to take effect. The `make build` command will do that for you (see the Makefile if you want to execute the steps manually). If you need to clean your current directory from compiled files, execute `make clean`. If you want to get rid of all files that are not under version control, run `make distclean` (Caution: If your changes are not under version control, this command will delete them!)

Now we will receive your pull request. We will check whether your changes are clean and make sense (if you talked to us before doing all of this we will have told you whether it makes sense or not). If so, we will pull them and you will get instant karma. Congratulations, you’re a hero!

## Documentation Contributions

Documentation contributions generally follow the same workflow as code contributions, just a bit more lax. We don’t ask you to go through all the hassle just to correct a single typo. For more complex contributions, please consider following the suggested workflow though.