Skip to content

Latest commit

 

History

History
60 lines (43 loc) · 2.93 KB

CONTRIBUTING.md

File metadata and controls

60 lines (43 loc) · 2.93 KB

How to contribute

We're really happy to see you here, since it means you're using Data Supply and want to improve it - just like us! While we've been thinking about this library for a long time, we have definitely not considered everything, and we also haven't had time to build out everything we've considered, so help is always appreciated!

As this is early days for the project there's not a lot in the way of resources, but please check out the documentation including the roadmap, and also the list of issues.

Signal Noise use Data Supply on lots of our studio work and so we have strong thoughts about what may or may not work as part of the library, but we encourage you to make suggestions, ask questions and generally help us make this suitable for as wide a range of use cases as possible.

For now, please submit an issue if you need help with anything. If this takes off we'll put more resources in place for support.

We have a code of conduct so please make sure you follow it.

Testing

We haven't yet put anything in place for testing - not even a harness. If you'd like to help with this please submit a PR!

Submitting changes

Please send a GitHub Pull Request to signal-noise/datasupply with a clear list of what you've done (read more about pull requests). When you send a pull request, please make sure you've covered off all the points in the template.

Make sure to add yourself to the Contributors list as well.

Please use Prettier with no overrides, and make sure you've read about our workflow (below); in essence make sure each Pull Request is atomic but don't worry too much about the commits themselves as we use squash-and-merge.

Our workflow

We use GitHub flow; it's a lot like git-flow but simpler and more forgiving. Some additional pieces we've put in place are:

  • We use the squash and merge strategy to merge Pull Requests.
  • QA is built from branches starting with release, e.g. release/v0.1. Only hotfixes should be committed to those branches.
  • Production is built from tags starting with a v, e.g. v0.1. The tags should be created from a release branch

In effect this means:

  • Don't worry about individual commits. They will be preserved, but not on the main main branch history, so feel free to commit early and often, using git as a save mechanism.
  • Your Pull Request title and description become very important; they are the history of the main branch and explain all the changes.
  • You ought to be able to find any previous version easily using GitHub tabs, or Releases

Thanks!