Skip to content

creating pull requests

Dan Kelley edited this page Mar 4, 2023 · 1 revision

If you plan on making a pull request, please ensure that your changes are as small as possible. For example, do not change the indentation of any existing code, change variable names because you prefer another, alter methods unless you know (and have communicated to the developers) that your method is superior, etc. It is also important that you follow the coding style of oce, in terms of indentation, variable names, spacing, etc. Let the existing code be your guide.

Avoid adding new dependencies.

Note that oce is built around base R. Therefore, please do not make suggestions to use ggplot, tibbles, magritter, etc. (This is obvious from inspection of the code, but it's important to say.)

Obviously, you ought to ensure that your pull request will not cause a merge conflict. There are tools for that. But it is also important that you check that your new version works at least as well as the existing version. Therefore, you ought to do the following checks (and note the results in your communications to the authors).

  • local build
  • local test (easy in RStudio, possible in any system)
  • local check (easy in RStudio, possible in any system)
  • devtools::spell_check() should produce no errors
  • urlchecker::url_check() should produce no errors
  • devtools::check_win_release() should return clean results

Does all of this seem daunting? Well, it has to be, because oce is complicated, and it has a very small development team. We don't have the resources to fix up problems with pull requests. Any pull request that covers more than a few lines is very likely to be rejected. And, pull requests that use a coding style that differs from that used in oce are almost certain to be rejected ... it's quite a lot easier for the developers to study your suggestion and write the code, than to have it be inserted and then need editing.