Add pull request lifecycle docs (#89)

contributing/README.md

@@ -2,6 +2,9 @@
 
 This directory contains documentation about the HCP Terraform Provider codebase, aimed at readers who are interested in making code contributions.
 
+To learn more about how to create issues and pull requests in this repository, and what happens after they are created, you may refer to the resources below:
+- [Pull Request submission and lifecycle](pull-request-lifecycle.md)
+
 ## Requirements
 
 - [Terraform](https://www.terraform.io/downloads.html) >= 0.13.x

contributing/pull-request-lifecycle.md

@@ -0,0 +1,46 @@
+# Pull Request Submission and Lifecycle
+
+__Note for internal service teams__: The pull request lifecycle below will be
+roughly the same for internal teams, but you will not need to fork the repo to
+create pull requests, and our recommendation is to get a review from one other
+member of your service team, in addition to a review from one member of the
+provider team.
+
+We appreciate direct contributions to the provider codebase. Here's what to
+expect:
+
+* For pull requests that follow the guidelines, we will proceed to reviewing
+  and merging, following the provider team's review schedule. There may be some
+  internal or community discussion needed before we can complete this.
+* Pull requests that don't follow the guidelines will be commented with what
+  they're missing. The person who submits the pull request or another community
+  member will need to address those requests before they move forward.
+
+## Pull Request Lifecycle
+
+1. [Fork the GitHub repository](https://help.github.com/en/articles/fork-a-repo),
+   modify the code, and [create a pull request](https://help.github.com/en/articles/creating-a-pull-request-from-a-fork).
+   You are welcome to submit your pull request for commentary or review before
+   it is fully completed by creating a [draft pull request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests).
+   Please include specific questions or items you'd like feedback on.
+
+1. Once you believe your pull request is ready to be reviewed, ensure the
+   pull request is not a draft pull request by [marking it ready for review](https://help.github.com/en/articles/changing-the-stage-of-a-pull-request) and a
+   maintainer will review it. Follow [the checklists](README.md#checklists)
+   to help ensure that your contribution can be easily reviewed and potentially
+   merged.
+
+1. One of the provider team members will look over your contribution and
+   either approve it or provide comments letting you know if there is anything
+   left to do. We do our best to keep up with the volume of PRs waiting for
+   review, but it may take some time depending on the complexity of the work.
+
+1. Once all outstanding comments and checklist items have been addressed, your
+   contribution will be merged! Merged PRs will be included in the next
+   provider release. The provider team takes care of updating the CHANGELOG and
+   releasing new versions of the provider. Please ask a provider team member
+   about the timing of the next release if the change you are making is
+   time-sensitive. Generally, releases are done roughly every two weeks.
+
+1. In some cases, we might decide that a PR should be closed without merging.
+   We'll make sure to provide clear reasoning when this happens.