summaryrefslogtreecommitdiff
path: root/dist/CONTRIBUTING.md
diff options
context:
space:
mode:
Diffstat (limited to 'dist/CONTRIBUTING.md')
-rw-r--r--dist/CONTRIBUTING.md54
1 files changed, 0 insertions, 54 deletions
diff --git a/dist/CONTRIBUTING.md b/dist/CONTRIBUTING.md
deleted file mode 100644
index 84c9893..0000000
--- a/dist/CONTRIBUTING.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Contributing to the UnderStrap Project
-We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
-
-- Reporting a bug
-- Discussing the current state of the code
-- Submitting a fix
-- Proposing new features
-- Becoming a maintainer
-
-## We Develop with Github
-We use github to host code, to track issues and feature requests, as well as accept pull requests.
-
-## We Use [Github Flow](https://guides.github.com/introduction/flow/index.html), So All Code Changes Happen Through Pull Requests
-Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
-
-1. Fork the repo and create your branch from `master`.
-2. If you've added code that should be tested, add tests.
-3. If you've changed APIs, update the documentation.
-4. Ensure the test suite passes.
-5. Make sure your code lints.
-6. Issue that pull request!
-
-## Any contributions you make will be under the GNU GPL version 2
-In short, when you submit code changes, your submissions are understood to be under the same [GNU GPL version 2](https://opensource.org/licenses/GPL-2.0) that covers the project. Feel free to contact the maintainers if that's a concern.
-
-## Report bugs using Github's [issues](https://github.com/understrap/understrap/issues)
-We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/understrap/understrap/issues/new) - it's that easy!
-
-## Write bug reports with detail, background, and sample code
-[This is an example](http://stackoverflow.com/q/12488905/180626) of a bug report I wrote, and I think it's not a bad model. Here's [another example from Craig Hockenberry](http://www.openradar.me/11905408), an app developer whom I greatly respect.
-
-**Great Bug Reports** tend to have:
-
-- A quick summary and/or background
-- Steps to reproduce
- - Be specific!
- - Give sample code if you can.
-- What you expected would happen
-- What actually happens
-- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
-
-People *love* thorough bug reports. I'm not even kidding.
-
-## Use a Consistent Coding Style
-
-* 2 spaces for indentation rather than tabs
-* Use ./.editorconfig if your editor supports it
-<!-- * You can try running `npm run lint` for style unification -->
-
-## License
-By contributing, you agree that your contributions will be licensed under GNU GPL version 2.
-
-## References
-This document was adapted from the open-source contribution guidelines for [Facebook's Draft](https://github.com/facebook/draft-js/blob/a9316a723f9e918afde44dea68b5f9f39b7d9b00/CONTRIBUTING.md)