Howto to do pull requests

If you want to contribute to a repository, you do not have write access to, you can create a fork of the repository and use pull requests to ask existing committers to accept your changes. A general technical introduction how to fork and create a pull request is provided by GitHub

[How to fork a repository](Fork tutorial)

How to file a pull request

Please also follow the contribution guidelines.

Additionally there are several rules you should follow to make the use of pull request efficient and most important easily allow committers to accept your pull request:

• Keep pull requests as small as possible. A committer has to review and understand all changes done in a pull request. If you combine several tasks into one pull request, the committer has no way to unerstand the single changes. As an example, if you want to review two different documents, file one pull request for each one.

• Try to minimize the time between the fork and the pull request. If the fork is very old, it is based on a version which is very different to the one, your changes are merged into, once you do a pull request. That might lead to outdated comments and more important makes the merge potentially more difficult

• Review your changes. Make sure your fork only contains changes you want to be transfered into the master repository. You can therefore review the history of the fork. Again, after filing the pull request, you need to review the actual diff. As a contributor it is your responsibility to keep the pull request clean.

• Avoid changes, which cannot easily be tracked by Git. Versioning systems such as git compare files on a line by line base to find out the differences. Therefore, certain changes make it very hard for Git to be correctly merged. As an example, if you rename a file and do not use special git commands, Git will understand a rename as a delete of the old file and as a new file added. If you change something in the renamed file within the same pull request, the committer has no way to find out, what that was.

• Keep the number of commits low on a fork. It is easier to diff one commit instead of many. As you should try to keep the number of changes low until you file a pull request, in most cases it is most efficient to only include one commit in a pull request. Please note that you can ammend to previous commmits or even squash commits in Git to create a history which is easy to be merged

• Avoid structural changes in a document. The more lines you change, the harder the merge will be. Adding some lines in a document is easy, moving a paragraph a little bit harder and finally reformating all lines almost produces a new document for git.

• Become a committer. If you frequently contribute to a document, please consider to become a committer on the project.

• Don't fork a fork: This makes pull requests hard to handle