Skip to content

Making a Pull Request

aeschylus edited this page Oct 11, 2014 · 13 revisions

We eagerly accept pull requests from any contributor so long as the following steps have been taken.

1. Issue

An issue was created for the proposed change or fix. This is to ensure there is a chance to publicly discuss the context of the change, preferably before a contributor goes through the process of implementing it.

2. Pull Request

The contributor forks the project (or, for committers, creates a separate branch) and issues a pull request through Github. The commit being submitted should have a descriptive and helpful commit message. For a thorough guide to the mechanics of making a pull request through Github, see Github's step-by-step guide. For more in-depth information about pull requests, see the longer article. In general the message should indicate why the commit was made and describe at a high (but specific) level what was done. Here is an article on what not to do. Note that git allows the programmer to revise the commit message of a previous commit, and Github allows you to directly address issues from the commit message, such that, when the change is merged, the issues' discussion pages will automatically be annotated with the relevant commit and close themselves.

3. Tests

A passing jasmine test is written and included as part of the pull request, covering the changed or added code appropriately. Travis declares that the codebase would pass its tests if the change is merged. For more information and an introduction on writing and testing javascript with jasmine, review the Development Tooling and Workflow wiki page.

4. Style

The code conforms to the style guide used throughout the rest of the code. We use idiomatic.js. For now this is determined by a code review conducted by a committer, but may be helped by a custom JSHint config in the near future.

We are happy to help any contributor through these steps for their first commits, so if you have a contribution, go ahead and submit the request and a committer will work through the testing, style, and commit message steps to incorporate your contribution. If a committer is not immediately available, there are usually other contributors who can help you in the #iiif IRC channel on Freenode. In general, we are eager to increase the test coverage of our codebase, so, in addition to issues tagged as "good entry project", adding tests is always a welcome contribution.