Update: Our contribution guidelines are now available at https://github.com/remotestorage/remotestorage.js/blob/master/CONTRIBUTING.md
first draft, comments and improvements welcome!
These guidelines are meant to safeguard the quality of our core remotestorage.js code. Please follow them, and also point other to them when reviewing their code.
remotestorage.js is an open community project and we very much welcome new contributors: anybody can join and start coding, without permission from anybody. If you follow the following step-by-step process strictly, it should be quite easy to land your patches in the next release!
-
step 1: open a github issue. in there, describe what needs fixing/adding. make sure you reply to all comments that are made on your issue, to ensure an effective discussion about whether this feature is actually desirable, what other issues are related/relevant, etc.
-
step 2: fork the
masterbranch in your local checkout of the remotestorage.js repo, and write your code. make sure to add unit tests and follow the style guide by running jshint on it. if you need help with anything, go to the #remotestorage irc channel on freenode, ask on this forum (http://community.remotestorage.io/), or discuss on your github issue. -
step 3: open a pull request. before pushing your code to github, make sure to rebase onto master and to squash all your commits into one (or maybe a couple) using
git rebase master -i. also, if your github issue is e.g. issue #123, then write “(fixes #123)” in the title of your pull request, so they’re linked. -
step 4: you will usually get a few comments suggesting improvements on each pull request, and especially in the beginning you should expect a bit of back-and-forth during the review process. respond to the comments and push new commits to your pull request that resolve the concerns of reviewers.
-
step 5: wait until your pull request has two positive reviews. a positive review is where someone has read your code, likes what it does and how it’s structured, has checked that it conforms with our guidelines, and writes “+1” in a comment. if your code changes a lot during step 4, you might want to ask early +1-ers to re-review, to make sure they still stand by their review.
-
step 6: once your pull request has no more open discussion issues, and two “
+1” reviews, dogit rebase master -iagain on the pull request to squash any commits that were added during the review, and then immediately merge it into master, and delete the branch. this will close the pull request as well as the issue it fixes. if you need help with the git commands, feel free to ask someone else to help with this. -
step 7: participate in the discussion on other people’s issues. after all, that is how we cooperate and help each other! And once a couple of your own pull requests have made it into master, you can also start +1-ing other people’s pull requests. just make sure you tick all the boxes during your review, as this is our only quality guard for the project’s core code.
-
step 8: once a month or so, we tag a release. master should always be ready to release, so that this process of actually tagging the release from master is pretty light-weight.
this is first draft, comments and improvements welcome!
.