Document the user workflow

Problem:
Access to this repo must be available to any user on github.

Solution:
Describe in README the acceptable workflow using the 'fork' option in
the github UI.

Signed-off-by: eccles <phewlett76@gmail.com>

Author: eccles

BUILDING.md

@@ -14,6 +14,10 @@ If you're addressing a bug, please explain how to reproduce it.
 ## Pull request and git commit guidance
 
 ### Opening PRs and organizing commits
+
+See the documented workflow described in the README.md file detailing the sequence of
+git commands required to submit a PR from a fork of this repo.
+
 PRs should generally address only 1 issue at a time. If you need to fix two bugs, open two separate PRs.
 This will keep the scope of your pull requests smaller and allow them to be reviewed and merged more quickly.
 
@@ -70,11 +74,12 @@ Generally, pull requests need two approvals from maintainers to be merged.
 
 When addressing review feedback, it is helpful to the reviewer if additional changes are made in new commits.
 This allows the reviewer to easily see the delta between what they previously reviewed and the changes you added
-to address their feedback.
+to address their feedback. These commits should be in the form of 'fixups' ('git commit --fixup HEAD').
 
 Once a PR has the necessary approvals, it can be merged.
+
 Here’s how the merge should be handled:
-- All PR's should use the “Squash and merge” option.
+- Once approved the author will be asked to squash all fixup commits generated by the review process.
 - Commits and their messages should be consistent - each commit in the PR should form a logical unit with working code. 
 - The first change requested by a Jitsuin reviewer will be to reorganise the commits into a clean logical structure.
 - The smaller a PR the more likely and more easily that the change will be approved.