OneStop is a data discovery system being built by CIRES researchers on a grant from the NOAA National Centers for Environmental Information. We welcome contributions from the community!
This project is maintained by cedardevs
Estimated Reading Time: 10 minutes
We’re so glad you’re thinking about contributing to the OneStop project! If you’re unsure about anything, just ask — or submit your issue or pull request anyway. The worst that can happen is we’ll politely ask you to change something. We appreciate all friendly contributions.
One of our goals is to ensure a welcoming environment for all contributors to our projects.
We encourage you to read this project’s contributing policy (you are here), its LICENSE and README.
To help us get a better understanding of the issue you’re submitting, include detailed steps to replicate the issue along with expected behavior.
Here are a few guidelines to follow when submitting a pull request:
Fork this repo into your Github account (or just clone it if you’re a OneStop team member). Read more about forking a repo on Github
master
that lightly defines what you’re working on (for example, add-styles).master
branch.Have questions or need help with setup? Open an issue via Github Issues
See the Quickstart deployment overview pages.
The purpose of our coding styleguides are to create consistent coding practices for OneStop. The styleguide should be treated as a guide — rules can be modified according to project needs.
We use code coverage tools to understand how much of our JavaScript is suffciciently tested. Code coverage is one way (among many) of measuring code quality more generally. Here’s how it works for contributions:
For JavaScript contributions, we will review the code coverage percentage and change to ensure that the quality of our code is not dramatically affected.
High code coverage numbers are generally good, and we would prefer that our coverage increases over time. We will not categorically reject contributions that reduce code coverage, but we may ask contributors to refactor their code, add new unit tests, or modify existing tests to avoid significant reductions in coverage.
See our branching model guidelines for more information on our internal git/GitHub release workflow.