Skip to content

Latest commit

 

History

History
35 lines (23 loc) · 2.92 KB

CONTRIBUTING.md

File metadata and controls

35 lines (23 loc) · 2.92 KB
Raw

Contributing to Sharetribe

First of all, thank you so much! We greatly appreciate all contributions. However, before you spend time working on Sharetribe, please read over our guidelines:

Reporting issues

Use the ISSUE_TEMPLATE.md to report issues. Here's an example issue: raw / formatted

If you'd like to know what happens after you've reported an Issue, see How to handle Github Issues

Bug fixes

  1. Fix the issue in a branch of your own fork of Sharetribe.
  2. Rebase your branch to include the latest changes from master. We do not accept pull requests with merge commits.
  3. Open a pull request from your fork to master.
  4. Make sure all the tests pass.
  5. Update CHANGELOG.md

New features

By default, we don't accept pull requests that introduce new features if it hasn’t been greenlighted by the Sharetribe team in advance.

Join the Sharetribe Development chat room in Flowdock and tell us what you are about to do (Update: The developer chatroom is not in use at the moment, see this issue). The team might be able to offer some suggestions on how to proceed. Features that don’t fit with Sharetribe’s vision and roadmap will not be accepted. Talking with the team is the best way to find out whether your feature is in line with Sharetribe’s plans.

From a technical point of view, the Sharetribe Ruby on Rails app is not always built using the traditional "Rails way". In addition to the MVC layers, additional API and Store layers are used to define self-contained boundaries inside the application. All new features have to follow this structure.

After you've received a go-ahead from the team:

  1. Start coding in a branch of your own fork of Sharetribe.
  2. Open a pull request from your fork to master as early as possible. Pull requests are a great way to start a conversation around a feature. If the pull request is work in progress and not yet ready to be reviewed, add a [WIP] prefix to the title.
  3. Make tests for your new feature. It’s the best way to guarantee that other developers don't accidentally break your feature.
  4. When you are ready, rebase your branch to include the latest changes from master.
  5. Make sure all the tests pass.
  6. Update CHANGELOG.md
  7. Remove the [WIP] prefix and ping the core team to review the pull request.