Skip to content

Latest commit

 

History

History
96 lines (75 loc) · 4.01 KB

CONTRIBUTING.md

File metadata and controls

96 lines (75 loc) · 4.01 KB
Raw

How to contribute

When contributing to this repository, please first discuss the change you wish to make via issue or the Gitter channel.

General feedback and discussions?

The number one place to be for discussion is our Gitter channel.

Bugs and feature requests?

For non-security related bugs, log a new issue in the appropriate GitHub repository. Here are some of the most common repositories:

Contributing code and content

We accept fixes and features! When you're ready to contribute, fork and clone the repo then run npm run setup .

  • "Help wanted" issues - these issues are up for grabs. Comment on an issue if you want to create a fix.
  • "Good first issue" issues - we think these are a good for newcomers.
  • "Documentation" issues - good documentation is at the core of crocks completing these issues will help you understand the library better as well as helping out the crocks community greatly.
  • Become very familiar with the structure of the docs Documentation it'll help you understand the structure submitted code should take.

Code of conduct

TBD

Identifying the scale & scope

Contributing to any open-source project is a noble endevour however it should be treated like any other professional project. First identify the scale and scope of what you would like to contribute. If it is simple and/or small (grammar/spelling or a bug fix) feel free to start straight away. If it is a new feature or the proposed change is substantial then it's important to discuss with the team and to begin breaking the problem down. Smaller tasks mean more people can work on it and the quicker the piece is completed. It could also not be in the direction of the project, we don't want you to waste your time! You might also read these two blogs posts on contributing code: Open Source Contribution Etiquette by Miguel de Icaza and Don't "Push" Your Pull Requests by Ilya Grigorik. All code submissions will be reviewed against the coding standards and tested/validated, only those that meet the bar for both quality and appropriateness will be merged into the source.

Submitting a pull request

We loosely follow the GitHub Flow process with our pull requests with a few minor additions

  1. Open a PR after your first commit - This ensures discussion can start early and any concerns can be discussed early
  2. Create a descriptive title and a detailed description. If possible reference the issue that the PR resolves.
  3. Commit often
  4. When you feel you're complete, request a review
  5. Work through any of the review comments
  6. Merge once approved
  7. Celebrate!

Tests

  • Tests need to be provided for every bug/feature that is completed.
  • 100% test coverage must be maintained

Feedback

Your pull request will now go through extensive checks by the team. Please be patient; we have full time jobs, but dedicate what spare time we can. Update your pull request according to feedback until it is approved by one of the team members.

Conclusion

Most importantly it's about just having fun and adding value to a package you already enjoy. All potential contributions will be evaluated fully on there own merit and given appropriate consideration. We look forward to see what you contribute!