Adding a CONTRIBUTING document

[tyler-ball]

Which describes acceptance criteria for all Chef Provisioning resources.

\cc @randomcamel @jkeiser @charlesjohnson

• Adding a CONTRIBUTING document chef-provisioning-aws#316
• Adding a CONTRIBUTING document chef-provisioning-azure#38
• Adding a CONTRIBUTING document  chef-provisioning-docker#64
• Adding a CONTRIBUTING document  chef-provisioning-fog#121
• Adding a CONTRIBUTING document  chef-provisioning-ssh#24
• Adding a CONTRIBUTING document  chef-provisioning-vagrant#30

[randomcamel]

👍 Slick.

[stuartpreston]

Excuse my naivety - why must all Chef Provisioning resources implement :create and :destroy actions?
What if 'create' is the wrong verb (e.g. deploy a CF template, or in my case an Azure Resource Manager one)

[tyler-ball]

@stuartpreston I think create is actually the wrong word - I would much more prefer converge as the default action. As you say, a Chef Resource may model an object which isn't actually created just interacted with. But the use of create as the default action goes wayyyyyyyy back.

If Chef Provisioning Azure should use some other actions, then we could update the CONTRIBUTING.md document there to say what the minimum set of actions the resources should respond to.

The goal here is not to force all Provisioning Resources to conform to a too-simple API, but rather to define a set of criteria so Resource authors know when their Resource is complete.