Skip to content

Latest commit

 

History

History
136 lines (86 loc) · 3.85 KB

CONTRIBUTING.md

File metadata and controls

136 lines (86 loc) · 3.85 KB
Raw

Introduction

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. In that way, this project is more like a wiki than a standard guarded open source project.

Contributing Pull Requests

Fork the Project

Fork the project on Github and check out your copy.

git clone https://github.com/contributor/color.git
cd color
git remote add upstream https://github.com/thisandagain/color.git

Create a Topic Branch

Make sure your fork is up-to-date and create a topic branch for your feature or bug fix.

git checkout master
git pull upstream master
git checkout -b my-feature-branch

Tools

Install CocoaPods and XCTool.

gem install cocoapods
brew install xctool

Pod Install and Test

Ensure that you can build the project and run tests.

pod install
xctool -workspace EDColor.xcworkspace -scheme Tests -sdk iphonesimulator build test

Write Tests

Try to write a test that reproduces the problem you're trying to fix or describes a feature that you want to build. We definitely appreciate pull requests that highlight or reproduce a problem, even without a fix.

Write Code

Implement your feature or bug fix. Make sure that all tests pass.

Write Documentation

Document any external behavior in the README.

Update Changelog

Add a line to CHANGELOG under Next Release. Make it look like every other line, including your name and link to your Github account.

Commit Changes

Make sure git knows your name and email address:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Writing good commit logs is important. A commit log should describe what changed and why.

git add ...
git commit

Push

git push origin my-feature-branch

Make a Pull Request

Go to https://github.com/contributor/color and select your feature branch. Click the 'Pull Request' button and fill out the form. Pull requests are usually reviewed within a few days.

Rebase

If you've been working on a change for a while, rebase with upstream/master.

git fetch upstream
git rebase upstream/master
git push origin my-feature-branch -f

Update CHANGELOG Again

Update the CHANGELOG with the pull request number. A typical entry looks as follows.

* [#123](https://github.com/thisandagain/color/pull/123): Reticulated splines - [@contributor](https://github.com/contributor).

Amend your previous commit and force push the changes to your branch.

git commit --amend
git push origin my-feature-branch -f

Check on Your Pull Request

Go back to your pull request after a few minutes and see whether it passed muster with Travis-CI. Everything should look green, otherwise fix issues and amend your commit as described above.

Be Patient

It's likely that your change will not be merged and that the nitpicky maintainers will ask you to do more, or fix seemingly benign problems. Hang on there!

Thank You

Please do know that we really appreciate and value your time and work. We love you, really.

Rules of Engagement

There are a few basic ground-rules for contributors on the master repo:

  1. No --force pushes or modifying the Git history in any way.
  2. Non-master branches ought to be used for ongoing work.
  3. External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
  4. Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
  5. Contributors should attempt to adhere to the prevailing code-style.

Releases

Declaring formal releases remains the prerogative of the project maintainer.