PR Guidelines

Pull Request Guide

We use a git "gatekeeper" workflow model, where every code change to the master branch, whether from the main developers or outside contributors, should be a pull request, which is then checked and possibly refined through reviews. How this works in detail is outlined below. If you have questions, feel free to ask in the tracker, we are happy to help.

• Every major change to mlr’s core system, i.e., training, resampling, pipelines, etc, has to be reviewed by 1-2 senior persons. 2 if something really "core" is changed in a non-trivial fashion.
• The pull request can contain multiple commits, they will be squashed when the pull request is merged. Since this is done automatically by GitHub, it's not necessary for you to squash yourself.
• Here is a minimal check list before pull requests can be merged. Do not deviate from this without asking / a proper reason!
  • Unit tests added/changed as appropriate. Every detected bug, major addition or change must result in a new, good test.
  • Did you think carefully about the names (especially exported functions) that you introduced? This is very important and hard to change later.
  • Did you document all arguments and return values, including their types?
  • For new algorithms: Did you include a reference to the paper that explains the method?
  • Please include examples on how the new function can be used in the documentation.
  • Did you use the appropriate functions for argument checking (mostly named assert_*()) from the checkmate package).
  • Please update NEWS.md with the respective changes.
  • Code readable, commented and follows the
    • Developer Guide and
    • Style Guide
  • Has the documentation in all relevant places been adapted? This includes the tutorial.
  • Make sure that only files are changed that are related to the PR. It can happen from time to time that your editor will add/remove whitespaces or indentation automatically.
  • Make sure that no spelling errors are in the documentation. Run a spell checker (in RStudio you can use F7)

General rules

• Use a proper editor for programming. Like vim, emacs, sublime, RStudio.
• Read and follow the style guide. If you use RStudio, these settings will help:

  • Whitespace after, e.g., if and for can be automatically identified in RStudio

    Tools -> Global Options... -> Code -> Diagnostics

    Activate "Show diagnostics for R" and "Provide R style diagnostics (e.g. whitespace)".

  • For proper indentation go to

    Tools -> Global Options... -> Code -> Editing

  • Check also the Options in

    Tools -> Project Options... -> Code Editing and activate "Ensure that source files end with newline" and "Strip trailing horizontal whitespace when saving".