Issues

Issues will be collected using GitHub’s issue trackers, one for each CHoRUS repo. Anyone can file an issue.

Assign an issue to a collaborator to indicate that person is working on it, or will be working on it shortly.

Issues can be labelled with the following default labels (package maintainers are free to add their own custom labels should they see a need):

Type of issue

  • bug Erroneous behavior that needs to be fixed. (Color #fc2929)
  • enhancement New functionality that could be added. (Color #84b6eb)
  • exploratory Changes that require some research first. (Color #fbca04)
  • question A questions that just needs an answer, not a change in code. (Color #cc317c)
  • duplicate Duplication of an existing issue. (Color #cccccc)

Issue collaboration

  • good first issue An issue that could be solved by someone new to the package. (Color #0052cc)
  • documentation Requires (re) writing of documentation, no coding. (Color #B7042F)
  • help wanted Will probably not be addressed by the package maintainer, but could be addressed by someone else. (Color #159818)

Pull requests

Before you open a pull request, you should always file an issue and make sure the package maintainer agrees that it’s a problem, and is happy with your basic proposal for fixing it. We don’t want you to spend a bunch of time on something that we don’t think is a good idea.

Additional requirements for pull requests:

  • Adhere to the Developer Guidelines posted here, as well as the OHDSI Code Style.

  • If possible, add unit tests for new functionality you add.

  • Restrict your pull request to solving the issue at hand. Do not try to ‘improve’ parts of the code that are not related to the issue. If you feel other parts of the code need better organization, create a separate issue for that.

  • Make sure you pass R check without errors and warnings before submitting.

  • Always target the develop branch, and make sure you are up-to-date with the develop branch.

Repo organization

CHoRUS tools rely on a variety of different languages and associated structures. We are working to define a standard format for each use case.

Coding guidelines

Some general coding guidelines:

Function calls must not have invisible side effects

When a user calls a function, the effect of that call should be apparent to the user. This means:

  • Do not call library or require in a function, as this changes the user’s search path.

  • Do not set options.

  • Do not write to files other than those specified by the user in the function call.

  • Do not use global variables.

Instead of using library, always explicitly reference the package a function belongs to, for example SqlRender::translate().

Avoid unnecessary dependencies

Dependencies lead to instability. Only add dependencies to other packages if completely unavoidable.

We have more or less accepted we need to depend on the core tidyverse packages, so any of those packages are allowed.

Use named arguments

Except for very simple function calls (e.g. print(x)), use named arguments, for example:

sql <- SqlRender::translate(sql = "SELECT * FROM my_table;", targetDialect = "postgresql")

instead of

sql <- SqlRender::translate("SELECT * FROM my_table;", "postgresql")