Contribution to this project is very welcome. You do not need to submit code to participate in this project, every bug you find and every improvement idea you have brings this project forward. Feel free to send your issues and pull requests to this project through GitHub. The project maintainer will comment on issues and pull requests as necessary.
However, please note that not every pull request might get merged into the project. Even though we value your contribution to this project a lot, the project maintainer does look very carefully at every pull request and makes sure that it improves the project in a whole and does not break with any old behavior for compatibility reasons. All our projects are used inside our own applications, so it is very important to us, to maintain a high quality standard, which you are participating from as well. We find it very important to provide the same quality and compatibility in our own frameworks that Apple provides in their own APIs. Therefore we might ask you to change a couple of things before a pull request is merged. These changes can lead from simple formatting or commit message fixes to general architectural changes. This is done to make sure, the code is readable and consistent. If you want to make sure that a pull request would be of interest for the project, feel free to file an improvement through the 'Issues' section to discuss your idea.
Please do not hesitate to post an issue for every bug or improvement you find. Before opening a new issue please check the existing issues to prevent filing duplicates.
If you have general questions, feel free to file them in the 'Issues' section but make sure to add the 'question' tag to it. If you have an issue or a question that you can not discuss in public, do not hesitate to contact the project maintainer directly.
If you want to start working on an issue that you want to file as a pull request, please leave a short notice in the issue to let everybody see that you are working on this and post status updates when appropriate.
Please open a pull request for every bug fix or improvement you want to share. Make sure every pull request only deals with one bug or feature and clearly state the issue number the pull request is related to in the description, if there is one.
If your pull request contains test coverage, your code is readable and well formatted, and your commit messages follow the guidelines described below, chances are high that your pull request will be merged quickly. Otherwise you might be asked to change things. In some cases we might add test coverage on our own, however, this might take some time.
If you want to implement a large feature or do other work that results in a lot of changes, please open an issue first or contact the project maintainer so that this can be discussed up front.
We think good commit messages are as important as a clean code structure. We do look at them very carefully. Please take your time and think about what changes to group in a commit and how to describe the commit.
A commit message should describe the changes in a way, that somebody who does not know the related issue or the state as it was before is able to understand the changes. All commit messages should be written in the imperative. This matches nicely with commit messages generated by git (e.g. merge commits) and is way more readable than other styles.
Don't: improved comments
Do: docs(presentation): add header comments for methods in MyViewClass
Your commit message should contain a summary, which is the first line of your commit message. It should be no longer than 70 characters.
The second line is always blank, followed by one or multiple paragraphs that describe the commit in detail. Each paragraph is separated by a blank line.
After the body, an optional footer can contain references to issues. If your commit contains a breaking change, this MUST be statet in the footer.
If there is nothing more to say than what fits in the first line, that is fine. However be sure that your changes are described very clearly!
We think that these rules are enough to have a consistent look, however if you want to read more about this topic, we find the style described in the camunda.org project to be very good.
We use the git flow workflow in all our projects and encourage you to do so, too. While this is not necessary to contribute to the project we strongly believe that this worflow makes working with many developers on one project a lot easier. To read more about git flow check out the blog post A successful Git branching model.