Contribution guidelines

Update: Our contribution guidelines are now available at

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 master branch 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 (, 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, do git rebase master -i again 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!

Edit: forget most of what I wrote except for “I’ll try to edit the format and make it more concise.”

Also, please nobody follow step 6!

I just pushed a first version to the rs.js repo:

Would probably make sense to put that link as an update on top of the post above, @michielbdejong.

Also, everybody please review and start PRs for changes!

Will also add a section about code quality/formatting etc soon.

Cool to see this thing evolving.

@raucao, please take into consideration to rename the file to and put it into / as GitHub will automatically link to it within its UI.

Good to be back after some illness and all those holidays.

Cool, will do. Thanks.

Done. Thanks again for the suggestion!

You’re most welcome.

But I have to return the favour, as I’ve found this in the Discourse repo, which I found by this community :smile:.
In the end. life remains recursive.