Adds label emojis and paves way for addition of GH project guidelines #…

…238

contributing.md

@@ -12,6 +12,11 @@ of changes for people _already familiar with dwyl's contributing process_.
 In time, the whole process will be rewritten for clarity and now that our focus
 has moved away from working with clients.
 
+> The vast majority of the additions here sit in two key areas:
++ New labels specific to this repo
++ The use of the [Github Project](https://help.github.com/en/github/managing-your-work-on-github/about-project-boards)
+as a kanban board (this is not yet in our main contributing guide)
+
 
 ## Part 1: Describe your Question, Idea or User Story in an Issue
 
@@ -28,27 +33,27 @@ the PO will also:
 + Acceptance Criteria should be in the form of a _checklist_ of items in the
  original post. This way it will appear in the issue list, giving an idea of
  how much of the acceptance criteria has been met when the issue is worked
- on 
+ on
  ![checklist-in-issue-list-screenshot](https://user-images.githubusercontent.com/4185328/69977981-a422bc80-1523-11ea-9df2-8e892dd6f884.png)
 
 
 + If no acceptance criteria is present, the PO should either:
- + Add the `needs-criteria` label to the issue to signal that this still
+ + :label: Add the `needs-criteria` label to the issue to signal that this still
  needs to be added before work can proceed; OR
  + Add acceptance criteria to the original post if they are intimately familiar
- with what is required 
+ with what is required
  ![needs-criteria-label-screenshot](https://user-images.githubusercontent.com/4185328/69977426-b2240d80-1522-11ea-95f3-8de79ce516fb.png)
 
 #### B) Confirm that there is a proposed User Interface *(UI)* for the issue
 
-Similar to `needs-criteria`, a `needs-ui` label should be applied to the issue
+:label: Similar to `needs-criteria`, a `needs-ui` label should be applied to the issue
 if no UI has been proposed and until a UI is agreed.
 
 _Note:_ This does not have to be the _final, unchangeable_ UI. Every UI is a
 starting point for testing with people using the app.
 
 ### Step 2: Assign a Priority to the Issue
-:warning: A priority label should only be used for the issues expected to come up
+:warning: :label: A priority label should only be used for the issues expected to come up
 in the next 2 sprints or so.
 
 All other issues - should a rough priority for them be known at this stage - will