@datasupply/datasupply
Version:
Data Supply is an opinionated data processing, provision and presentation library of components for Javascript
61 lines (43 loc) • 3 kB
Markdown
# 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](./index.md) including the
[roadmap](./roadmap.md), and also the
[list of issues](https://github.com/signal-noise/datasupply/issues).
[Signal Noise](https://signalnoise.io) 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](./CODE_OF_CONDUCT.md) 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](https://github.com/signal-noise/datasupply/pull/new/main)
with a clear list of what you've done (read more about
[pull requests](http://help.github.com/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](https://allcontributors.org/docs/en/bot/usage) to the Contributors list as well.
Please use [Prettier](https://prettier.io/docs/en/index.html) 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](https://guides.github.com/introduction/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](https://github.com/signal-noise/datasupply/releases)
Thanks!