CONTRIBUTING.md
In dselivanov/RestRserve: A Framework for Building HTTP API

Interested in contributing? Great! We really welcome bug reports and pull requests that expand and improve the functionality of RestRserve from all contributors.

chat on gitter
post a question on Stack Overflow using the [restrserve] tag

make sure the issue is a bug report and not a question or feature request
one issue for one purpose. Don't report more than one bug or request several features in the same issue
feel free to add reactions to existing issues that are important to you. We monitor this and it helps us prioritize where to devote our efforts

Please share your feedback in this github ticket

If you are not fixing an open issue please consider to file a new issue before submitting the PR. So, It may save you time to create an issue first and start a discussion to see if your idea would be accepted in principle. If you are going to spend more than a day on the PR, creating an issue first lets other people know you are working on it to save duplicating effort.
The PR's status must be passing tests before we will start to look at it
every new feature or bug fix must have one or more new tests in inst/tests/
please create the PR against the dev branch
just one feature/bugfix per PR please. Small changes are easier to review and accept than big sweeping changes. Sometimes big sweeping changes are needed and we just have to discuss those case by case
github enables us to squash commits together when merging, so you don't have to squash yourself

Please don't put "feature request" items into GitHub Issues. If there's a new feature that you want to see added to RestRserve, you'll need to write the code yourself - or convince someone else to partner with you to write the code (we love feature submissions!). If you enter a wish list item in GitHub Issues with no code, you can expect it to be marked "invalid" as soon as it's reviewed.

Sometimes, the line between 'bug' and 'feature' is a hard one to draw. Generally, a feature is anything that adds new behavior, while a bug is anything that causes incorrect behavior.

If you need some feature but don't have capacity/experience to work on it you can ask fot support at https://rexy.ai/ or hello@rexy.ai.

We use lint in order to have consistent code style.

In a nutshell:

do as other files do and do not invent a new style
use = for assignment (not <-); see here, here, here and here
for R6 classes we use CamelCase
for the rest we use snake_case
we don't use . inside names
other then that stick to base R style
Spacing
2-space indentation
No trailing white space
Add a whitespace between if and opening bracket, also before opening curly bracket: if (condition) {
Use L suffix for integer; i.e. x[1L] not x[1] (to save coercion)