NA

Contributing to RestRserve

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

Asking Questions

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

Bug reports

  • 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

Feedback

Please share your feedback in this github ticket

Pull Requests (PRs)

  • 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

Feature requests

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.

Programming Style

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)