architecture-decision-record.txt

Title: A short description of the decision to be made, this is similar to an 
  email subject
Date: The Date the decision was made
Participants: List the people involved in the decision. This can make it easier
  to get more information later
Context: Provide as much context around the problem as possible.
  This should include any factors at play including; technological, political, 
  social and anything else. This should be fact based and in full sentences.
Decisions: Describe the decision made and the reasons why in full sentences.  
Consequences: Describe the resulting context after applying the decision. All
  consequences should be listed here, positive, negative, and neutral. They
  affect the team and project in the future.
Review Triggers: Provide any factors that would cause a re-evaluation of the
  decision. Examples of this might be newer versions of software, assumptions
  or situations changing

## Some guidelines ##

###Create an entry when###
  * A lot of time is taken to a decision
  * The decision is crusial to achieving a requirement
  * The decision or options are confusing at first
  * The decision has widespread impacts
  * the decision is difficult to undo
  
### Tips ###  
  * Store the decision record where decisions are made or people would expect 
  to find it
  * Decisions should never be deleted, even when new decisions replace old one.
  This all adds to the context and can be important in the future.
  * Review the decision record regularly to keep it relevant.

References:
  https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records
--------------------------------------------------------------------------------

Title: 
Date: 
Participants: 
Context: 
Decisions: 
Consequences: 
Review Triggers: 

--------------------------------------------------------------------------------