Contributing Guidelines

Inspired from ReactiveCocoa and Alamofire guidelines.

This document contains information and guidelines about contributing to this project. Please read it before you start participating.

Topics

Asking Questions
Reporting Security Issues
Reporting Issues
Contributing with code
Developers Certificate of Origin
Code of Conduct

Asking Questions

We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.

Reporting Other Issues

A great way to contribute to the project is to send a detailed issue when you encounter an problem. We always appreciate a well-written, thorough bug report.

Check that the project issues database doesn't already include that problem or suggestion before submitting an issue. If you find a match, add a quick "+1" or "I have this problem too." Doing this helps prioritize the most common problems and requests.

When reporting issues, please include the following:

The version of Xcode you're using
The version of iOS or OS X you're targeting
The full output of any stack trace or compiler error
A code snippet that reproduces the described behavior, if applicable
Any other details that would be useful in understanding the problem

This information will help us review and fix your issue faster.

Prefer Pull Requests

If you know exactly how to implement the feature being suggested or fix the bug being reported, please open a pull request instead of an issue. Pull requests are easier than patches or inline code blocks for discussing and merging the changes.

If you can't make the change yourself, please open an issue after making sure that one isn't already logged.

Contributing Code

Fork this repository, make it awesomer (preferably in a branch named for the topic), send a pull request!

All code contributions should match our coding conventions.

Thanks for contributing! 💥🐫

Contributing with code

PR requirements

Every PR proposing a feature or a bug fixing must include unit tests
CI integration script must pass (it's currently Travis)
Components must be marked as public/private/internal/final depending on its scope

Rake tasks

In order to simplify some tasks there's a set of tasks defined in a Makefile that you can use:

Build all schemes: make ci
Run tests: make test

New version checklist

make ci passes.
make tests passes.
Bump the version in project targets.
Bump the version in SugarRecord.podspec.
Close the issues that have been fixed.
Update the wiki with the last changes.
Tag the last commit with the proper version.
Create a Release entry on Github and update the CHANGELOG.md document.
Archive Carthage framework and upload it with the Release on Github.

Public / Private / Internal / Final

Public: Mark as public all the components that will be used by the consumer of the library. In case you have doubts if it should or shouldn't be public think about yourself using SugarRecord and using that component. What if it wasn't public?
Internal: Default visibility (also by default in Swift). If the component is going to be used internally and has to be tested make it internal. Be careful because it's the default visibility and you might leave it as an internal and even test it but when any developer tries to use it he can't...
Private: If the component doesn't have to be exposed out of your framework scope and you don't have to test it make it private. An example of private components are constants.
Final: If the class shouldn't be extendible, don't forget specifying it with the final keyword.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

Code of Conduct

The Code of Conduct governs how we behave in public or in private whenever the project will be judged by our actions. We expect it to be honored by everyone who contributes to this project.

See CONDUCT.md for details.

Some of the ideas and wording for the statements above were based on work by the Docker and Linux communities. We commend them for their efforts to facilitate collaboration in their projects.

6.1 KiB Raw Blame History