anchor.diff:  By participating in this project you agree to abide by its terms.
   [Contributor Code of Conduct](https://voxpupuli.org/coc/).
   
  -1. Fork the repo.
  -
  -1. Create a separate branch for your change.
  -
  -1. We only take pull requests with passing tests, and documentation. [travis-ci](http://travis-ci.org)
  -   runs the tests for us. You can also execute them locally. This is explained
  -   in a later section.
  -
  -1. Checkout [our docs](https://voxpupuli.org/docs/#reviewing-a-module-pr) we
  -   use to review a module and the [official styleguide](https://puppet.com/docs/puppet/6.0/style_guide.html).
  -   They provide some guidance for new code that might help you before you submit a pull request.
  -
  -1. Add a test for your change. Only refactoring and documentation
  -   changes require no new tests. If you are adding functionality
  -   or fixing a bug, please add a test.
  -
  -1. Squash your commits down into logical components. Make sure to rebase
  -   against our current master.
  -
  -1. Push the branch to your fork and submit a pull request.
  -
  -Please be prepared to repeat some of these steps as our contributors review
  -your code.
  +* Fork the repo.
  +* Create a separate branch for your change.
  +* We only take pull requests with passing tests, and documentation. [travis-ci](http://travis-ci.org) runs the tests for us. You can also execute them locally. This is explained [in a later section](#the-test-matrix).
  +* Checkout [our docs](https://voxpupuli.org/docs/reviewing_pr/) we use to review a module and the [official styleguide](https://puppet.com/docs/puppet/6.0/style_guide.html). They provide some guidance for new code that might help you before you submit a pull request.
  +* Add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, please add a test.
  +* Squash your commits down into logical components. Make sure to rebase against our current master.
  +* Push the branch to your fork and submit a pull request.
  +
  +Please be prepared to repeat some of these steps as our contributors review your code.
  +
  +## Writing proper commits - short version
  +
  +* Make commits of logical units.
  +* Check for unnecessary whitespace with "git diff --check" before committing.
  +* Commit using Unix line endings (check the settings around "crlf" in git-config(1)).
  +* Do not check in commented out code or unneeded files.
  +* The first line of the commit message should be a short description (50 characters is the soft limit, excluding ticket number(s)), and should skip the full stop.
  +* Associate the issue in the message. The first line should include the issue number in the form "(#XXXX) Rest of message".
  +* The body should provide a meaningful commit message, which:
  +  *uses the imperative, present tense: `change`, not `changed` or `changes`.
  +  * includes motivation for the change, and contrasts its implementation with the previous behavior.
  +  * Make sure that you have tests for the bug you are fixing, or feature you are adding.
  +  * Make sure the test suites passes after your commit:
  +  * When introducing a new feature, make sure it is properly documented in the README.md
  +
  +## Writing proper commits - long version
  +
  +  1.  Make separate commits for logically separate changes.
  +
  +      Please break your commits down into logically consistent units
  +      which include new or changed tests relevant to the rest of the
  +      change.  The goal of doing this is to make the diff easier to
  +      read for whoever is reviewing your code.  In general, the easier
  +      your diff is to read, the more likely someone will be happy to
  +      review it and get it into the code base.
  +
  +      If you are going to refactor a piece of code, please do so as a
  +      separate commit from your feature or bug fix changes.
  +
  +      We also really appreciate changes that include tests to make
  +      sure the bug is not re-introduced, and that the feature is not
  +      accidentally broken.
  +
  +      Describe the technical detail of the change(s).  If your
  +      description starts to get too long, that is a good sign that you
  +      probably need to split up your commit into more finely grained
  +      pieces.
  +
  +      Commits which plainly describe the things which help
  +      reviewers check the patch and future developers understand the
  +      code are much more likely to be merged in with a minimum of
  +      bike-shedding or requested changes.  Ideally, the commit message
  +      would include information, and be in a form suitable for
  +      inclusion in the release notes for the version of Puppet that
  +      includes them.
  +
  +      Please also check that you are not introducing any trailing
  +      whitespace or other "whitespace errors".  You can do this by
  +      running "git diff --check" on your changes before you commit.
  +
  +  2.  Sending your patches
  +
  +      To submit your changes via a GitHub pull request, we _highly_
  +      recommend that you have them on a topic branch, instead of
  +      directly on `master`.
  +      It makes things much easier to keep track of, especially if
  +      you decide to work on another thing before your first change
  +      is merged in.
  +
  +      GitHub has some pretty good
  +      [general documentation](http://help.github.com/) on using
  +      their site.  They also have documentation on
  +      [creating pull requests](http://help.github.com/send-pull-requests/).
  +
  +      In general, after pushing your topic branch up to your
  +      repository on GitHub, you can switch to the branch in the
  +      GitHub UI and click "Pull Request" towards the top of the page
  +      in order to open a pull request.
  +
  +
  +  3.  Update the related GitHub issue.
  +
  +      If there is a GitHub issue associated with the change you
  +      submitted, then you should update the ticket to include the
  +      location of your branch, along with any other commentary you
  +      may wish to make.
   
   ## Dependencies
   
  
positive.code: bundle exec rake rubocop
  ```
  
  ## Running the unit tests
  
  The unit test suite covers most of the code, as mentioned above please
  add tests if you're adding new functionality. If you've not used
  
negative.code: --jobs "$(sysctl -n hw.ncpu)"
  ```
  
  ## The test matrix
  
  ### Syntax and style
  
  The test suite will run [Puppet Lint](http://puppet-lint.com/) and
  [Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to
  