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: 
  === Feature Requests
  
  Pull Requests that don't qualify for a patch release should
  
  1. target the _develop_ branch or a relevant feature branch.
  2. Once a Pull Request has been approved it can be
  3. scheduled for a major/minor release by updating the milestone label.
  4. Only when a Pull Request is approved *and* scheduled for the next minor release it can be merged
  into the _develop_ branch, only then can
  5. the issue/feature branch can be closed.
  
  Minor and major releases require a formal https://www.eclipse.org/projects/handbook/#release-review[release review], and because this is the case, they need to be planned well in advance, and the project lead needs to manage what can go into each release, and prepare necessary documentation (both technical and legal) for review.
  For this reason approved Pull Requests may stay open for some time until a
  release plan that incorporates these changes is in place.
  
  == Patch releases
  
  
negative.code: 
  4. Push the newly created branch, as follows:
  +
      git push origin releases/2.1.6
  
  Bug fixes are typically added to a hotfix release branch by https://git-scm.com/docs/git-cherry-pick[cherry-picking] the relevant commits from the _master_ branch. 
  
  