-
Notifications
You must be signed in to change notification settings - Fork 3
Contribution Guidelines
Rock-Native is NewSpring's open sourced project to build apps for the web, iOS, and Android. This project is under heavy active development and is the next generation of our website and apps. Our desire is that this project would be easy to contribute to. Hopefully, this document sheds some light on our processes, and how you can contribute.
Table of Contents
Our team works 100% off of Github, and it should always remain updated with what is currently in active development.
Our team works off of individual feature branches which eventually get merged into
master before being deployed. Since this is the case, the master branch may at
times contain bugs or API changes that haven't been fully communicated or tested,
and may break older versions of the app.
We will do our best to keep master in working order, with all tests passing. For
a stable release of the app, you can always explore our past and current releases.
We work off of pull requests pretty heavily, and therefore we monitor for new PR's. When considering pull requests, we may require more than one person to sign off, so these can sometimes take a day or two.
One way you can contribute is by tackling some known issues.
We are using GitHub Issues for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.
The best way to get a bug fixed is to provide an example case of where the problem is occurring. Images or videos of the failure occurring is beneficial where applicable. If you think you have a solution to a bug and would like to fix it, let us know. We can hopefully provide recommendations, as well as let you know if the bug is in fact intended behavior.
We track feature requests using Github Issues. If you would like to begin a discussion about a new or improved feature, open a new issue.
When working to fix bugs or add features, we recommend opening a pull request early so we can comment on it or request any changes early on. It is also recommended that you work off of open issues, and let us know on them what you will be working on for the same reason.
Please submit your pull request on the master branch.
Before submitting a pull request, please make sure the following is done…
- Fork the repo and create your branch from
master. -
Describe your test plan in your commit. If you've added code that should be tested, add tests in
__tests__subfolders. - Ensure tests pass on Travis. These automatically run when opening a pull request.
- Make sure your code lints (
yarn lint). - Make sure your code is typed using flow (
yarn flow). - Rebase your code to master (
git rebase). Stating one-line intentions along with each commit helps the reviewer to understand what you're changing.
- Above all, pay attention to the template shown when creating issues.
- Before opening an issue, search existing issues and closed issues for any current or past discussion about your topic.
- Try to limit each commit to one change.
- Commits messages should be short and clear.
- Feel free to reference issues and pull requests in commit messages.
- Refer to the above instructions on what to do before opening a pull request.
- Follow instructions on the pull request template shown when opening a new pull request.
- Most important: Look around. Match the style you see used in the rest of the project. This includes formatting, naming things in code, naming things in documentation.
- Add trailing commas where necessary.
- 2 spaces for indentation (no tabs)
- "Attractive"
- We use
prettier, so a lot of the formatting should be taken care of for you. But if you have a question, please ask!
- Use semicolons;
- Prefer
"over' - 100 character line length
- Prefer
"over'for string literal props - When wrapping opening tags over multiple lines, place one prop per line
-
{}of props should hug their values (no spaces) - Place the closing
>of opening tags on the same line as the last prop - Place the closing
/>of self-closing tags on their own line and left-align them with the opening<
By contributing to Rock-Native, you agree that your contributions will be licensed under its MIT license.