anchor.diff:  
   Once a issue is complete and tested, a Pull Request should be created for
   peer review.
  +If the issue is part of a larger feature, the PR should be branched from
  +(and target) the corresponding `features/` branch.
  +If the issue is a new feature in and of itself, the PR should be branched from
  +(and target) the _develop_ branch.
  +If the issue is a bug fix, the PR should be branched from
  +(and target) the _master_ branch.
   
   === Patch Requests
   
   If the change is a bug fix, contains no new features, and
  -does not change any public or protected APIs (class or method signatures in the
  -core module, i.e. code included in the release archive) then
  -
  -1. the Pull Request should target the _master_ branch. Once the Pull Request is created
  -2. it should be reviewed and any modifications can be made to the issue branch as recommended.
  -3. Once a Pull Request has been approved it can be
  -4. scheduled for a patch release (if not already) by updating the milestone label.
  -5. Only when a Pull Request is approved *and* scheduled for the next patch release it can be merged
  +does not change any public or protected APIs then
  +
  +1. Create an _issue_ branch by forking the _master_ branch.
  +2. Make the necessary changes and verify the codebase.
  +3. Create a Pull Request that targets the _master_ branch.
  +4. Peers and project committers now have a chance to review the PR and make suggestions.
  +5. Any modifications can be made to the _issue_ branch as recommended.
  +6. Once any necessary changes have been made, project committers can mark the PR as approved.
  +7. Project committers should then determine what patch release this fix will be included in by updating the milestone label.
  +8. Only when a Pull Request is approved *and* scheduled for the next patch release it should be merged
   into the _master_ branch then
  -6. the issue branch can be closed.
  -7. After a PR has been merged into the _master_ branch, the _master_ branch should
  -then be merged into the _develop_ branch and any conflicts (such as due to new
  -features) should be resolved.
  +9. the issue branch can be delete (if desired).
  +10. After a PR has been merged into the _master_ branch, the _master_ branch should
  +then be merged into the _develop_ branch by the project committer that merged the PR,
  +any conflicts (such as due to new features) should be resolved.
   This can be done from the command line from a clean checkout as follows:
   
       git checkout develop
  
positive.code: release deployment. Once release deployment is complete, the release branch
  is deleted.
  
  IMPORTANT: It is important that the _master_ branch is always in a release ready state, so
  a patch release from the _master_ branch can be done in an ad-hoc fashion,
  without the need for a formal review.
  
  Plans to do a patch release are announced by the project lead on the
  https://dev.eclipse.org/mailman/listinfo/rdf4j-dev[rdf4j-dev@eclipse.org mailinglist],
  
negative.code: 2. Tag the version and push the tag upstream:
  +
      git tag 2.1.6
      git push origin 2.1.6
  
  Once the release is complete, the hotfix branch needs to be deleted. Although this can of course be done from the command line, it is cumbersome, and we recommend using a decent Git client (like SourceTree) that can do this for you.
  
  