Skip to contents

Opening issues

The easiest way to note any behavioural curiosities or to request any new features is by opening a github issue.

Development guidelines

If you’d like to contribute changes to bikedata, we use the GitHub flow for proposing, submitting, reviewing, and accepting changes. If you haven’t done this before, there’s a nice overview of git here, as well as best practices for submitting pull requests here.

The bikedata coding style diverges somewhat from this commonly used R style guide, primarily in the following two ways, both of which improve code readability: (1) All curly braces are vertically aligned:

this <- function ()
{
    x <- 1
}

and not

this <- function(){
    x <- 1
}

and (2) Also highlighted in that code is the additional whitespace which permeates bikedata code. Words of text are separated by whitespace, and so code words should be too:

this <- function1 (function2 (x))

and not

this <- function1(function2(x))

with the natural result that one ends up writing

this <- function ()

with a space between function and (). That’s it.

Code of Conduct

We want to encourage a warm, welcoming, and safe environment for contributing to this project. See the code of conduct for more information.