| # Contributing to OCMock |
| |
| First off, thanks for taking the time to contribute to OCMock! |
| |
| The following is a set of guidelines for contributing to OCMock. These are just guidelines, not rules. Use your best judgment and feel free to propose changes to this document in a pull request. |
| |
| This project adheres to the [Contributor Covenant 1.2](http://contributor-covenant.org/version/1/2/0). By participating, you are expected to uphold this code. |
| |
| |
| ## Submitting issues |
| |
| * If you have a question about using OCMock, please do not open an issue. Ask the question on StackOverflow using the [ocmock](http://stackoverflow.com/questions/tagged/ocmock) tag. |
| |
| * If you have encountered an issue or you want to suggest an enhancement, perform a [cursory search](https://github.com/erikdoe/ocmock/issues?q=is%3Aissue) to see if a similar issue has already been submitted. |
| |
| * When you submit an issue, please try to provide a [minimal, complete, and verifiable example](http://stackoverflow.com/help/mcve), ideally with a failing unit test. The easier it is to understand and reproduce the issue, the more likely it is that we can provide a fix. |
| |
| * Include the version of OCMock you are using. If applicable include names and versions of other testing frameworks involved. |
| |
| * Include stacktraces; they are immensely helpful. |
| |
| |
| ## Pull requests |
| |
| * Create all pull requests from `master`. Do not include other pull requests that have not been merged yet. |
| |
| * Limit each pull request to one feature. If you have made several changes, please submit multiple pull requests. Do not include seemingly trival changes, e.g. upgrading the Xcode version, in a pull request for a feature or bugfix. |
| |
| * If you add a new feature provide tests that specify how the feature works. |
| |
| * If you have to add files, please make sure that the code builds for the OS X framework and the iOS library using Xcode. Also try to make sure that the Cocoapod and Carthage builds work. |
| |
| * Respect the coding conventions (see below). |
| |
| * Do not include the number of a related issue in the title of a pull request. Give the pull request a descriptive title and reference any issues from the description. |
| |
| * Once you have created the pull request, an automated build is kicked off on [Travis CI](https://travis-ci.org/erikdoe/ocmock/pull_requests). Please verify after a few minutes that the build on the server succeeded. Pull requests with failing builds are ignored and will be closed within a few weeks if they are not fixed. |
| |
| * Please don't post comments like "Ping?" or similar on your own pull requests. I understand that it can be frustrating not to get a response quickly but, unfortunately, I often don't have time to work on OCMock and can't always look at pull requests as they come in. It's difficult for me to predict when I'll get a chance to do so, but rest assured, pull requests are definitely not ignored. |
| |
| |
| ## Coding conventions |
| |
| Please remember that OCMock has been around for 10+ years. Some of the coding conventions used in OCMock may contradict modern guidelines. However, in the interest of keeping the codebase consistent, please respect the conventions used. In particular: |
| |
| * Opening and closing braces always go on a separate line. |
| * No spaces between keywords like `if` and `for` and the following bracket. |
| * No underscores for instance variables. |
| * OCMock itself (framework and library) does not use ARC; retains and releases must be sent manually. The unit tests, however, do use ARC. |
