anchor.diff:  * Product owner conceives high level idea
   * Business analyst writes story
   * Developer adds a new feature (addition example)
  -* Developer asks qa to approve (manual pull request)
  +* Developer asks QA to approve (manual pull request)
   * QA person commits it to master
   * Tools person moves it to production (via cara reprovision)
   
  
positive.code: 
  NOTE: In this section, we will create an additional repository for the QA person, who becomes the collaborative development partner (like Bill in the Atlassian writeup).
  
  QA, once you have received the task from the developer:
  
  Starting as your public ID, log into manos:
  
   :~/Calavera$ vagrant ssh manos5
  
  
negative.code: 
  * https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow[Centralized Workflow]
  * https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow[Feature Branch Workflow]
  (It is not required to read the further sections on Gitflow or forking workflow, but you may wish to do so for your own professional development. Source workflow is a critical topic for development organizations and the examples here are only the simplest.)
  
  We have been doing the centralized git workflow. For this lab you are to work with the feature branch workflow approach.
  
  NOTE: We do not have a capability for automated git pull requests within Calavera. (We do not use Github *within* Calavera. We just use plain git.)
  Therefore, your pull requests will have to be handled manually in your Kanban workflow. More below.
  
  === Identify a new feature
  Your product feature idea can be extremely simple. Some good starter examples would be:
  
  * Display the team name
  * Add two numbers together
  