Add a contributing guide

CONTRIBUTING.md

@@ -0,0 +1,49 @@
+# Contributing
+
+This library is maintained by and for the community of NetBox users. As such, the regular contribution of accurate and
+complete device type definitions is crucial to its success.
+
+## Writing Definition Files
+
+Each NetBox device type definition exists as a single YAML file, arranged by manufacturer (vendor). Files are named by
+concatenating the definition's model name with a `.yaml` extension. For example:
+
+```no-highlight
+vendors/Acme/BFR-1000.yaml
+vendors/Acme/BFR-2000.yaml
+```
+
+When writing new definitions, there are some important guidelines to follow:
+
+* Every unique model number requires a discrete definition file, even if the set of components is identical.
+* Include only components which are fixed to the chassis. Optional modular components should be omitted from the
+  definition. (Note that this does not exclude field-replaceable hardware that is expected to always be present, such
+  as power supplies.)
+* Name components exactly as they appear in the device's operating system (as opposed to the physical chassis label, if
+  different).
+
+Additionally, be sure to adhere to the following style guidance:
+
+* Do not begin the file with three dashes (`---`); YAML directives are not supported.
+* Use two spaces for indenting.
+* Specify a device type's attributes before listing its components.
+* Avoid encapsulating YAML values in quotes unless necessary to avoid a syntax error.
+
+## The Contribution Workflow
+
+The process of submitting new definitions to the library is as follows:
+
+1. Verify that the proposed definition does not duplicate or conflict with an existing definition. (If unsure, please
+   raise an issue seeking clarification prior to submitting a PR.)
+2. [Fork](https://guides.github.com/activities/forking/) the GitHub project and create a new branch to hold your
+   proposed changes.
+3. Introduce the new content exactly as it should appear once accepted.
+4. Submit a [pull request](https://github.com/netbox-community/devicetype-library/compare?expand=1) to merge your new
+   branch into the `master` branch. Include a brief description of the changes introduced in the PR.
+5. GitHub will automatically run tests against your PR to validate it. If the tests fail, make the necessary changes to
+   your branch so that they pass (or rescind the PR until you are able to do so). Please note that PRs which do not pass
+   validation will be closed.
+5. A maintainer will review your PR and take one of three actions:
+   * Accept and merge it
+   * Request revisions
+   * Close the PR citing a reason (e.g. failing validation or not applicable to the library)

README.md

@@ -1,15 +1,15 @@
-**NOTE:** We are not currently accepting pull requests to this library. An announcement will be made once the functionality is ready.
+**NOTE:** We are not currently accepting pull requests to this library. An announcement will be made once the
+functionality is ready.
 
 # About this Library
 
-This library is intended to be used for populating device types in [NetBox](https://github.com/netbox-community/netbox). It contains a set of device type definitions expressed in YAML and arranged by manufacturer. Each file represents a discrete physical device type (e.g. make and model). These definitions can be loaded into NetBox to obviate the need to create device types and their associated components manually.
+This library is intended to be used for populating device types in [NetBox](https://github.com/netbox-community/netbox).
+It contains a set of device type definitions expressed in YAML and arranged by manufacturer. Each file represents a
+discrete physical device type (e.g. make and model). These definitions can be loaded into NetBox to obviate the need to
+create device types and their associated components manually.
 
-# Guidelines for Defining Device Types
-
-* Every unique model number requires a discrete definition file, even if the set of components is identical.
-* Include only components which are fixed to the chassis. Optional modular components should be omitted from the definition.
-* Name components as they appear in the device's operating system (as opposed to the physical chassis label, if different).
-* Avoid encapulating YAML values in quotes unless necessary to avoid a syntax error.
+If you would like to contribute to this library, please read through our [contributing guide](CONTRIBUTING.md) before
+submitting content.
 
 # Device Type Definitions
 
@@ -17,18 +17,21 @@ Each definition must include at minimum the following fields:
 
 * `manufacturer`: The name of the manufacturer which produces this device type.
 * `model`: The model number of the device type. This must be unique per manufacturer.
-* `slug`: A URL-friendly representation of the model number. Like the model number, this must be unique per manufacturer.
+* `slug`: A URL-friendly representation of the model number. Like the model number, this must be unique per
+  manufacturer.
 
 The following fields may optionally be declared:
 
 * `part_number`: An alternative representation of the model number (e.g. a SKU).
 * `u_height`: The height of the device type in rack units. (Default: 1)
-* `is_full_depth`: A boolean which indicates whether the device type consumes both the front and rear rack faces. (Default: true)
-* `subdevice_role`: Indicicates that this is a `parent` or `child` device. (Default: None)
+* `is_full_depth`: A boolean which indicates whether the device type consumes both the front and rear rack faces.
+  (Default: true)
+* `subdevice_role`: Indicates that this is a `parent` or `child` device. (Default: None)
 
 ## Component Definitions
 
-Valid component types are listed below. Each type of component must declare a list of the individual component templates to be added.
+Valid component types are listed below. Each type of component must declare a list of the individual component templates
+to be added.
 
 * `console-ports`
 * `console-server-ports`
@@ -87,4 +90,3 @@ The available fields for each type of component are listed below.
 ### Device Bays
 
 * `name`: Bay name
-